Your team wants to rewrite a service that works. How do you decide, and how do you say no if that is the answer?

Find out what the ask is really about

A rewrite proposal is rarely only about the code, and a manager who evaluates it purely on technical merit will get the decision right or wrong by luck. There are four common motives underneath, they call for different responses, and they arrive in the same words.

Sometimes the service genuinely costs more to change than it should, and the team can demonstrate it. Sometimes the team dislikes the technology, which is a real cost in hiring and morale but a much weaker case than they will present it as. Sometimes the proposal is a growth ask in disguise: the engineer who wants to lead something has correctly identified that there is nothing else of that scale on the roadmap. And sometimes it is a retention flag, where the honest translation is that the work has stopped being interesting.

You need to know which, and you find out by asking what changes for a user, what changes for the team, and what happens if the answer is not this quarter. The last question is the informative one. If the response is a specific list of things that get worse — a compliance change that cannot be made safely, a growth curve the current design will hit — you have a case. If the response is disappointment, you have a motive rather than a case, and you owe the person a different conversation rather than a rewrite.

Make them measure the status quo

The strongest thing you can do is refuse to argue about the new design at all until the cost of the current one is a number. Ask for three measurements, all of which can be taken from records you already hold.

How much engineer time went into support, incidents and defects on this service over the last two quarters. How long a typical change to it takes, compared with a comparable change elsewhere in the estate. And how often a change to it caused a rollback or an incident. That is enough to distinguish a service that is genuinely expensive from a service that is merely old and unloved, and the exercise itself frequently ends the conversation in one direction or the other.

Then do the arithmetic in the open. Suppose the measurement shows the service consumed six engineer-months across the last six months in support and change overhead, so about one engineer-month per month. Suppose the team estimates the rewrite at four engineers for five months, which is twenty engineer-months. If the rewrite removed that overhead entirely, it pays back in twenty months. It will not remove it entirely, so at a realistic half the saving, the payback is closer to forty months. Set that against your team's capacity: eight engineers over a year is ninety-six engineer-months, and if measured interrupt work takes a fifth of it you have about seventy-seven for planned work, so twenty engineer-months is roughly a quarter of the year's planned output.

Every input there is stated and every one is challengeable, which is the point. A team that thinks the estimate is wrong can argue about the estimate rather than about whether you value quality. And if your organisation has a history of rewrite estimates overrunning, apply that multiplier explicitly and say where it comes from; if you have no such history, say that too rather than inventing a factor.

Test the incremental route properly

The default alternative is to strangle the old service rather than replace it: put the new implementation behind the same interface, move one endpoint or one category of traffic at a time, and keep both running until the old one has no callers. This is nearly always available, and it is better on almost every dimension that matters to you — it delivers value before it is finished, it can be abandoned halfway with the benefit already banked, and it never requires a single frightening cutover.

It is also slower in total, and the team will say so. That objection is correct and does not usually win, because the comparison is not between two ways of finishing but between a route that pays out continuously and a route that pays out only if it completes. Rewrites that are cancelled at seventy per cent produce nothing, and rewrites get cancelled when a quarter's priorities change, which they do.

There are real cases where incremental does not work, and you should be able to name them rather than dismissing the objection. If the data model itself is the problem, running two implementations means running two schemas and reconciling them, which can cost more than the rewrite. If the interface is what needs replacing, then there is no stable seam to hide behind. If the platform is genuinely end-of-life with a hard external date, the choice has already been made for you. A team that can articulate which of these applies has done the work; a team that says "it is all too tangled" has not looked.

Saying no in a way that survives

If the answer is no, do not deliver it as a priority decision alone, because "the roadmap comes first" tells the team that quality is what happens when there is spare time, and you will hear it repeated back to you for a year. Deliver it as the arithmetic, and then do three things.

Say what the case would have to look like to succeed, in terms of the measurements above, so the answer is "not on this evidence" rather than "not ever". Fund the part that is cheap and real: the three worst modules, the test coverage that makes changes safe, the observability that turns a three-hour incident into a twenty-minute one. And deal separately with the motive you diagnosed, because if the underlying ask was for something big to own, refusing the rewrite without offering an alternative loses you the engineer whether or not the technical decision was right.

Be explicit about your own mode when you do this. An engineering manager's opinion is heard as an instruction whether or not it is meant as one, so say plainly whether you are asking a question, giving input, or making the decision. "I am deciding this one, and here is why" is easier to work with than an opinion the team has to guess the weight of.

Agree the stopping condition before you start

If the answer is yes, the failure mode to design against is not a bad architecture. It is a rewrite that is ninety per cent complete for two quarters while the old service still carries all the traffic and the team maintains both. That state costs double and delivers nothing, and it is entered gradually rather than decided.

So set the terms in advance, in writing. Real traffic on the new path within a defined early window, however small a slice. A stated point at which the old service takes no new features, and a plan for what happens to urgent requests that arrive for it. Checkpoints where continuing is a decision rather than an assumption, with the criterion named — for instance, that if less than half of traffic has moved by month three, you stop and reassess rather than push on. And an explicit answer to what happens if the rewrite is cancelled at halfway, because a plan that produces nothing when interrupted is a plan you have not stress-tested.

Naming the condition on which you would stop your own team's rewrite is the part that most distinguishes a manager with judgement from one with enthusiasm, and it is much easier to agree before anybody has spent four months on it.