What are the alternatives to a large consultancy for supporting a legacy line-of-business application?

Why a large consultancy is often the wrong size

A large consultancy brings bench depth, formal process and the ability to put several people on a problem at once. That fits an organisation with a large estate of systems, a regulated environment that needs formal governance, or a legacy application that is one part of a wider programme.

The risk is that a single line-of-business application is too small for the engagement. The system gets whoever is on the bench, the people rotate, and the process overhead that suits a large programme is paid for on a small one. A consultancy also has little reason to keep an old system alive when a replacement programme would be a larger engagement, so be alert to a proposal that begins with a rewrite.

A specialist software company

A small company whose business is maintaining and modernising existing systems. CodeFirst is one, and our software maintenance page shows the terms we work to; the points below apply to any such company, including us.

What to check. Can they read the code: ask which of your technologies the people who would do the work have maintained, and ask to meet them. Do they take over systems they did not build, and how: a company that starts by proving it can build, release and restore the system is doing the right thing, while one that quotes for support without having seen the code is guessing. What does the contract cover: hours, how to raise a problem, response times by severity, what counts as chargeable change and who owns the code.

When it fits: the system matters, needs attention through the year, and you want more than one person behind it without a consultancy-sized engagement. The risk: a small company has fewer people and a narrower range of technologies, and it could itself close or be bought. The protection is the same as with any supplier: the code in a repository you own, the accounts in your name and a written handback.

An individual contractor

Often the cheapest by the hour, and a good contractor who knows your system can be very effective. When it fits: the system needs little attention, you have technical staff who can review the work, and a few days’ wait for a fix is acceptable.

The risk is the single point of failure. Holidays, illness and a better contract elsewhere all stop the work, and what the contractor knows usually stays in their head. If your organisation is medium or large, the off-payroll working rules also make you responsible for deciding the contractor’s employment status, so take advice. Our comparison of a support contract and a contractor goes through the trade-off in detail.

The original supplier, if it still trades

Nobody knows the system better, in principle. In practice the people who wrote it may have moved on, the supplier may have lost interest in a system it no longer sells, and it may price support knowing that you have nowhere else to go.

When it fits: the supplier still has the people and treats the system as a product it maintains. Before relying on it, confirm that you hold the current source code and the right to use it. If you do not, that is the first thing to settle, whoever supports the system afterwards.

An in-house hire

Having the knowledge inside the organisation is attractive, and if you have several systems there may be enough work for a full-time person. The difficulty is recruitment and retention. Developers willing to spend their time on old code are scarce, the ones you recruit tend to want to modernise it, and when the hire leaves you are back to one person’s knowledge walking out of the door.

When it fits: enough work to keep someone busy, a career path that is not only maintenance, and a second person or a supplier who can cover. Our comparison of a software company and an in-house developer sets out the costs on each side.

An offshore team

Usually the lowest cost for a given amount of development time, and many offshore firms do excellent work. The conditions are a technical lead on your side who can specify and check the work, requirements settled enough to be handed over in writing, and attention to the contract: which law governs it, where personal data will be handled and what you receive if it ends.

When it fits: a large amount of defined work and someone in-house to direct it. The risk: without that person you depend on the supplier’s account of its own work, and a time-zone gap slows the back-and-forth that an undocumented old system generates. Our page on a UK software company or an offshore team covers the differences fairly.

How to choose

Three questions settle most cases. What does it cost the business when the system is down? Can anyone on your side check the work? How much work does the system need in a year? A critical system with nobody to check the work points towards a company with a contract. A quiet system with technical staff in-house points towards a contractor or a hire.

Then put the same questions to every candidate and write down the answers. Our list of questions to ask a software supplier covers the people, ownership, pricing and leaving. Whichever you choose, keep the source code, the accounts and the documentation in your organisation’s hands, so that the choice can be changed later.