Outsourcing your application maintenance: criteria, risks and steps

Outsourcing application maintenance means entrusting a provider with the fixes, updates and enhancements of an application, while keeping the decision. The operation succeeds on three points: a written scope, commitments that can be measured and an exit planned from the day of signing. This guide reviews what outsourcing covers, when it is justified, its risks and how to carry it out.

It is aimed at business leaders, IT directors and product managers who have an application in service and are wondering who should maintain it. Application maintenance, often called third-party application maintenance (TMA), is not insurance against outages: it is an organisation, with its own rules.

What outsourcing application maintenance covers

We speak of “third-party application maintenance” (TMA) when a third party maintains an application it did not necessarily write. The general administrative terms for public contracts in information and communication technologies, the CCAG-TIC 2021, give a definition that is useful well beyond public contracts: TMA groups the services that keep an information system in a state allowing it to fulfil its function, and it can also cover the evolution or adaptation of software.

The same article distinguishes four families of work. They are what structure a maintenance scope. The fourth, evolutive maintenance, is the subject of a separate guide.

Source: CCAG-TIC 2021, Article 38 (order of 30 March 2021). The examples are ours.

What application maintenance does not automatically include is operations. The same text defines managed IT services as the outsourcing of the management or operation of all or part of the IT system, and specifies that they can cover third-party application maintenance or the hosting of infrastructure. One contract can combine the two, but they are two separate scopes: who hosts, who monitors, who backs up and who restores must be written down.

When to outsource, and when to keep it in-house

Outsourcing is not the answer to everything. It is justified in fairly recognisable situations.

• The application is in service and stable, but the team that built it is committed to new projects.
• Its technology stack requires skills that the company has no intention of recruiting.
• The maintenance workload is irregular: too small for a full-time post, too heavy in bursts to be absorbed.
• Security updates are falling behind for lack of availability.
• The company wants a framework: tracked requests, written commitments, a single point of contact.

Conversely, it is better to keep maintenance in-house in three cases.

• The application is the core of the product and changes every week: maintenance cannot be separated from development.
• Business knowledge is written down nowhere and rests only with the current team: it must be documented first.
• The company already has a team sized for this, with up-to-date documentation.

Between the two, a mixed arrangement exists: the in-house team keeps the roadmap and the structural changes, while the provider takes the preventive, corrective and adaptive work.

What you never outsource

Outsourcing execution does not mean delegating the decision. Four things stay in the company, whatever the provider.

• Priorities. What is fixed first, what waits, what will not be done: this is a business trade-off.
• Code ownership. With an external provider, it requires a written assignment of rights: paying for a development is not enough to hold the rights to it, as Bpifrance Création points out.
• Accounts and access. Code repository, hosting, domain name, third-party services: they are in the company’s name, and the provider is invited in.
• Business knowledge. An internal contact who knows what the application must do, and why.

These decisions need someone to carry them. If the company no longer has a technical director, or does not have one yet, an interim CTO can take on this role while the outsourcing is scoped and a hire is made.

The three risks, and how to cover them

A fourth point is not a risk but an obligation. If the application processes personal data, the provider acts as a processor within the meaning of the GDPR. Article 28 of the GDPR requires a written contract. It provides in particular that the processor processes the data only on documented instructions, ensures its confidentiality and security, engages another processor only with written authorisation, and deletes or returns the data at the end of the service.

Choosing the provider: what to look at

Sales presentations all look alike. The answers to these six points do not.

• Experience on your technology stack. Who will actually work on it, and on which comparable applications?
• The entry phase. Does the provider start with an audit of what exists, and what does the document delivered contain?
• Tooling. Request tracking, automated deployment, monitoring: what the provider brings, and what will remain with you at the end of the contract.
• Transparency of tracking. Can you see the requests, their status and the time spent without having to ask?
• Continuity. Do several people know your application, and what is planned for leave and absences?
• Language and working hours. A nearby provider or a French-speaking nearshore partner: what matters is common working hours and exchanges in your language.

The steps of an outsourcing

• Scope it. List the applications concerned, their criticality, what is expected and what stays in-house.
• Have what exists audited. The provider reads the code, installs it, and examines the versions, tests, deployment and backups before committing.
• Organise the transition. Transfer of access, handover with the current team, first supervised interventions.
• Move to steady state. Tracked requests, planned updates, regular reports: this is the normal way an application maintenance (TMA) service operates.
• Steer. A periodic review of requests, incidents, the state of the application and upcoming priorities.

The transition deserves a written schedule. As a benchmark, the CCAG-TIC 2021 provides, for public managed IT services contracts, a transition period of at most six months: this is the phase during which technical responsibility passes to the new provider. A private contract sets its own freely, but it is best to put a limit on it.

The contract: three clauses not to neglect

• Scope. The applications covered, the families of work included, what falls under operations, and what is quoted separately.
• Service levels. For managed IT services, the CCAG-TIC 2021 requires the contract documents to define the expected service levels, the means of measuring them and the penalties for non-compliance. The logic holds for a private contract: a commitment that cannot be measured cannot be enforced.
• Reversibility. Article 42 of the same text distinguishes reversibility (the client takes the services back, or entrusts them to a third party it designates) from transferability (a new provider takes them over), both described in a plan. Provide for this plan from signing: what is handed over to you, in which formats, with what assistance.

These three clauses are not the only ones. Our guide to the application maintenance contract reviews the nine clauses to check before signing, from remuneration to code ownership.

Frequently asked questions

Outsourcing your application maintenance: start with the scope

Outsourcing application maintenance comes down to a few things: knowing what you are handing over, keeping what cannot be delegated, measuring what is promised and planning the exit. The rest, tools and organisation, follows.

To go further, the iones team carries out the audit and application maintenance of existing applications. You can also write to us for an initial discussion.