Replacing the development company you have

Replacing the firm that built your software is a different problem from hiring one, and it usually goes wrong in the order of operations. The instinct is to give notice first and find a replacement second, because the relationship is the thing you want to end. The order that works is the reverse: secure ownership and access, buy an independent read on what you actually have, agree what happens to the existing system while its successor is built, and only then set a date. Every week spent on the first three is a week in which the incumbent is still under contract and still answering questions, which is the cheapest their knowledge will ever be. After the final invoice it is a favour, and then it is gone.

The element buyers leave out has a name, and the evidence that it gets left out is public. When the US Government Accountability Office examined the ten federal legacy systems most in need of modernisation, it measured each agency’s plan against three elements drawn from best practice: milestones, “a description of the work necessary to complete the modernization,” and “a plan for the disposition of the legacy system.” Three of the ten agencies — Education, Health and Human Services, and Transportation — had no documented modernisation plan at all. Of the seven that did, only two, the Departments of the Interior and Defense, included all three elements. GAO’s conclusion is the sentence worth keeping: “Until the other eight agencies establish complete modernization plans, they will have an increased risk of cost overruns, schedule delays, and project failure” (US Government Accountability Office, Information Technology: Agencies Need to Develop Modernization Plans for Critical Legacy Systems, GAO-19-471, June 2019). Two complete plans out of ten, inside organisations with statutory oversight and an auditor. A company changing vendors has neither, and the element it skips is the third one.

Disposition is the expensive omission. While the replacement is being built, the existing system keeps running, keeps costing, keeps needing a certificate renewal and a security patch, and keeps being the place your customers’ data actually lives. Somebody has to operate it, and once the incumbent has gone that somebody is you or the new firm, at a price nobody quoted. The federal picture is a useful check on how the money divides: of what the US government spends on information technology, GAO records that “About 80 percent of this amount is used to operate and maintain existing IT investments, including aging (also called legacy) systems.” Most of the cost of software is not building it. A transition plan that budgets only the build has budgeted the smaller half, and the overlap — two firms on the payroll — is the line item cut first and missed most.

Now the conflict, stated before any advice that rests on it. The firm best placed to tell you whether your existing codebase is worth keeping is a firm that would be paid to replace it. Nobody in that conversation is neutral, us included: we are an engineering firm, and a rewrite is a larger invoice than a takeover. So do not ask a candidate whether the code is any good; you are asking a question whose answer they are paid for. Buy a read instead — a small, separately priced piece of work with a written output, delivered before any build is scoped, in which keep it is one of the permitted findings and the document is yours either way. Our rescue engagement opens with exactly that shape: an audit in the first week or two whose stated job is to say what is salvageable and what is not. Point at the structure, not the promise. A firm that will only give you an opinion inside a proposal has given you a sales document.

The knowledge problem is structural too, and larger than most buyers assume. Eurostat reports that in 2024, “20.05% of EU enterprises employed ICT specialists” — and that in 2023, “in 71.92% of EU enterprises external suppliers performed the ICT functions,” against 39.52% in which the ICT functions were performed by their own employees, the two figures overlapping because an enterprise can do both (Eurostat, ICT specialists — statistics on hard-to-fill vacancies in enterprises, data extracted June 2025). Four fifths of enterprises employ no ICT specialist at all, and roughly seven in ten depend on an outside supplier for the function. Replacing that supplier is therefore not a swap between interchangeable providers. For most organisations it is the transfer of the only copy of the knowledge, from people who are leaving to people who have never seen it, with nobody in the middle able to check the handover.

Secure these before you give notice, in roughly the order that matters if it turns unfriendly. Root ownership of the cloud account rather than an administrator login inside it. The domain, at a registrar where your company is the registrant of record. The repositories, with their history, in an organisation you control. Production credentials and the deployment pipeline. A full data export you have personally run and loaded somewhere else. And the third-party contracts — payments, transactional email, error tracking, app store accounts — with the billing party and renewal date against each. The handover you must receive is the itemised version, and it is worth reading whole rather than paraphrased here, because in a replacement you are collecting all of it under time pressure from a party who has stopped having a reason to help.

Be fair to the incumbent, for an entirely selfish reason: if the fault is yours it will follow you. The buyer’s guide this article supports works through eight ways a build goes wrong and attributes four of them to the buyer or to both sides. Those four survive a change of vendor: a scope that moved every week, requirements nobody wrote down, product decisions that waited three weeks for an answer, no single person empowered to say no. So before the search starts, write down what you would have to change, specifically enough that a colleague could disagree with it. If that page comes out blank, the problem is probably not the vendor. Then ask the outgoing firm what went wrong and mean it, which is the highest-yield conversation in a transition and the one almost nobody has, because by that point both sides want it finished. What did they need from you and not get, what did they raise that never got an answer, what would they tell the incoming team on day one, and which part of the system do they consider riskiest? Put those to the engineers rather than the account manager, for the same reason a reference call works better with a participant than with a sponsor.

Scope the new firm’s first month as a takeover, not as features. Three deliverables, in order. A reproducible environment, proved rather than documented: an engineer who has never seen the system goes from a clean machine to a running local copy following written instructions, and every question they must ask is a defect in the documentation, fixed while somebody is still paid to fix it. A production change, small and real, shipped end to end by the new team through whatever pipeline already exists — a validation rule, a label, a log line — because that one move exercises deploy access, review, rollback and monitoring together, and it is the only thing that proves they can operate what they inherited rather than merely read it. And a written risk register naming the parts nobody understands yet, each with a cost attached to finding out. If a candidate proposes starting with a rewrite of the data model instead, you have learned something useful for free.

On rewriting, the honest position is that it is usually the wrong first move and occasionally the only one. It is right when the system cannot be run at all without its original authors, when the platform underneath it is out of support, or when the next thing you need is structurally impossible in what exists. It is wrong far more often than it is proposed, and the tell is that the argument arrives before anyone has run the code. Age by itself is not an argument. Among the ten systems in that same GAO review the ages ran from 8 to 51 years, and the problems identified were specific and checkable rather than atmospheric: obsolete hardware no longer supported by its manufacturers, a Department of Homeland Security system carrying reported vulnerabilities of which “168 were considered high or critical risk to the network as of September 2018,” and a Department of Education system written in a language with “a dwindling number of people available with the skills needed to support it.” Those are conditions you can verify in an afternoon. It is legacy is not a condition, it is a mood.

Four questions belong to this situation and to no other, and as with any screening question the failing answer is the useful half. How long before you can deploy to production yourselves, and what do you need from us to get there? An answer in months means a rewrite is being planned whatever the proposal says. What will you not touch in the first quarter, and why? No answer means no plan, only appetite. What do you expect the previous team got right? A firm that can find nothing is either not looking or is selling, and both are disqualifying in a takeover where you will be relying on their reading of somebody else’s work. And who talks to the outgoing vendor, about what, and in writing? The answer should be one named person and a short list of topics, because an unmanaged channel between two firms during a transition is where the blame travels and the knowledge does not.

When not to replace at all is a longer list than it feels. When you are weeks from a launch and the system works — finish, then move, because a transition during a launch is two risks multiplying rather than adding. When the remaining work is smaller than the cost of the transfer, which you can estimate: a takeover consumes real weeks before it produces anything visible. When nobody on your side will hold the knowledge afterwards, in which case you are scheduling this same month again in two years. And when the replacement is a way of avoiding a conversation with your own team about what the product is supposed to do — the most expensive avoidance available, because it buys a year of activity and answers nothing.

The version of this that goes well is unglamorous and slower than it feels it should be: overlap the two firms deliberately, pay for the overlap, and treat the first month as evidence gathering rather than velocity. Absorbing a system somebody else built is most of what a long engagement consists of and almost none of what a feature list shows — consolidating an operator portal, a headless CMS and a data pipeline for Cove, a US home-security device ecosystem whose content, device provisioning and subscriptions had been managed in three disconnected systems, ran across 24 months on that basis. The criteria for any top saas development company apply equally to the firm you are leaving and the firm you are joining, including the one we publicly fail, and they are worth running on the incumbent before you conclude that the incumbent was the problem. The replacements that work are the ones with a written plan carrying GAO’s three elements — milestones, the work required, and what happens to the old system — owned by the buyer rather than the vendor.