Nine checks you can run on a legacy system in an afternoon, without a discovery workshop and without talking to us.
Rewrite, Strangle, Wrap or Leave is a decision framework from Moweb Technologies for choosing what to do with a legacy system. Nine checks - covering the system's change rate, its failure modes, its dependencies, its data, and who still understands it - resolve to one of four outcomes: rewrite it, strangle it by replacing capability incrementally, wrap it behind an interface and leave the core intact, or leave it alone entirely. Leaving it alone is a real outcome rather than a fallback, and is the right answer whenever the system is stable, understood, and not blocking anything the business needs to do next.
When a system is described as unmaintainable, the constraint is usually not the language it was written in. It is that the rules the business depends on were never written down anywhere except in the behaviour of the running system, and a rewrite quietly drops the ones nobody remembered to mention.
These nine checks are designed to surface that before anyone estimates anything. Each is answerable from your own system by your own team. One of the four outcomes below is to change nothing, and it is genuinely the right answer more often than a company that sells modernisation would like it to be.
None of these needs tooling or an external audit. Write the answers down before reading the outcomes.
Not on the build server that has been running for six years. On a laptop with nothing installed, from the repository, following written steps.
What it tells you. If it does not, you do not have a codebase you control - you have a running instance. Nothing else on this list can be assessed reliably until that is fixed, and fixing it is usually days rather than months.
Any coverage counts. The question is whether something will tell you when behaviour changes.
What it tells you. With no tests, a rewrite is a bet that you can re-specify behaviour nobody has written down. Characterisation tests written against the current system are almost always the cheapest first move, whatever you decide afterwards.
Check the version you actually run, against the vendor's own support policy, not the project's latest release.
What it tells you. This changes urgency more than any other single answer. An unsupported runtime on an internet-facing system is a risk decision; the same runtime on an isolated internal system is a maintenance decision.
Application code, or stored procedures, triggers, scheduled jobs and constraints the app enforces that the schema does not?
What it tells you. Logic scattered outside the application is the most common reason rewrites silently drop rules. The more that sits in the database and in cron, the more a rewrite is a discovery project wearing an engineering estimate.
Not the code - the rules. Why the discount is calculated that way, why that customer type is exempt.
What it tells you. If yes, almost any path is viable and you should move while that is still true. If no, preservation work comes before any change, because the system is currently the only remaining specification.
A per-CPU licence, a dongle, a specific OS version, an integration with a device that speaks one protocol.
What it tells you. These constraints usually decide the answer on their own, and they are the ones most often discovered late. Establish them before anyone estimates anything.
Reporting tools, another department's application, an integration writing directly into tables.
What it tells you. A shared schema means the database is a public interface whether or not anyone intended it. That usually rules out a clean rewrite and points toward gradual replacement behind a stable interface.
Weekly, quarterly, or only when something breaks?
What it tells you. Deployment frequency is a proxy for how frightening the system is to change. A system nobody dares deploy will not survive a gradual migration, because that approach requires frequent small releases.
Retention obligations, residency requirements, audit trails you must be able to produce.
What it tells you. Regulation constrains where the system can run and what can be discarded, which narrows the options before technical preference gets a say.
Listed deliberately with the least invasive first, because that is the order in which they should be ruled out.
When: Stable, still patched, not blocking anything, and understood by someone.
The most under-recommended answer in this category. A system that does its job, receives security updates and is not preventing the business from doing something is not a problem waiting to be solved - it is working software. Isolate it properly, keep it patched, put it on the roadmap as a watch item, and spend the budget where the business is actually constrained.
Watch for. This is a decision to be revisited, not forgotten. It needs a named owner and a date, or it becomes neglect by default.
When: The system works, but other things need to talk to it and cannot.
Put an interface in front of it and leave the internals alone. New systems integrate with the interface rather than the schema, which buys most of the benefit of modernisation for a fraction of the risk, and leaves the door open to replacing what is behind it later.
Watch for. The wrapper must become the only way in. If direct database access continues alongside it, you have added a system rather than gained an interface.
When: Large, business-critical, and cannot stop.
Route by route, moving functionality out from behind a stable interface while the old system keeps serving what has not moved yet. This is the right answer for most large enterprise systems, because it keeps the business running and lets you stop at any point with something coherent.
Watch for. Agree the exit criteria and who funds the last twenty percent before the first route moves. The characteristic failure is stalling part-finished and paying to run both indefinitely.
When: Small enough to rebuild predictably, or the current structure is itself the problem.
Genuinely the right call sometimes: when the system is small, when its architecture is what blocks the business, or when the domain has changed so much that preserving current behaviour is not desirable.
Watch for. Rarer than it is chosen. A rewrite preserves what is specified, and in an old system a great deal is not specified anywhere except in the running code.
The questions this raises most often, including whether a rewrite is ever right.
Check 5, whether anyone still understands the domain rules. Every other constraint can be worked around with time and money. Undocumented rules held only by people who have left cannot be recovered by reading code alone, because the code shows what happens and not which parts are deliberate. If the answer is no, preservation work comes before any change of direction.
Proof
Send the answers and we will tell you which of the four we would recommend and why, including when the recommendation is to leave it running and spend the money elsewhere.
