Every organisation eventually owns something that has started to slip: a landing page with outdated details, a workflow that needs a manual workaround, a directory listing that no longer matches reality. The reflex is usually to build a fresh replacement, because new work is visible and fixing is not. A more disciplined response is to compare three options on their merits. You can repair the asset, replace it, or retire it. Each has a place, and the right choice depends on questions that are easy to ask and surprisingly rarely asked.<\/p>\n
Repair means keeping the asset in service and correcting its faults. It is the right choice when the underlying purpose is still valid and the problems are local: a broken address, a stale paragraph, a misconfigured setting. Repair is cheap, quick and preserves whatever history the asset has earned, including search visibility and the familiarity of the people who use it.<\/p>\n
Its weakness is that repair can become a habit that disguises a deeper problem. If you are patching the same component every month, the pattern itself is information. A single repair is maintenance; a repeating one is a verdict.<\/p>\n
Replacement means building a successor and switching over. It makes sense when the asset’s design no longer fits the job, when the cost of continued patching exceeds the cost of a rebuild, or when something about the original cannot be fixed at all. Replacement offers the chance to correct structural mistakes rather than their symptoms.<\/p>\n
The cost is larger than it looks. A replacement needs planning, migration, redirects from the old address, and a period in which both versions exist. It also creates a new asset that itself will need upkeep, which is the part most often left out of the business case. Our guide to combining web services, cloud hosting and automation in a growing business<\/a> is a useful companion when the replacement involves several moving parts.<\/p>\n Retirement means removing the asset on purpose. It is the least popular option and frequently the best one. If nobody uses the item, if its function has been absorbed elsewhere, or if keeping it alive creates risk without return, then the economical answer is to switch it off cleanly. Retirement should include a short note of what was removed, when, and where visitors are sent instead.<\/p>\n The downside is irreversibility. Retire the wrong thing and you may only find out when someone asks for it. A sensible safeguard is a holding period: take the asset out of public view, wait a defined interval, and delete it only if nobody objects.<\/p>\n Rather than debating preferences, put the asset through a short, consistent screen:<\/p>\n All three options depend on knowing the true condition of the asset, and condition is the thing that slips out of sight. Digital assets are especially prone to this because their failures are silent. A page can stay online while the links on it quietly lead nowhere. A listing can look perfect to its owner and baffle a visitor.<\/p>\n Links are a good illustration, since the decision between repair, replace and retire applies to them as well. A link to a moved page should be repaired. A link to a discontinued resource should be replaced with the best current alternative. A link to nothing at all should be retired. To make those decisions you first need to know which links are in trouble, and this is where a link-management platform like URLSnow<\/a> earns its keep, because its automatic health checks flag the entries that have stopped responding so you review the exceptions rather than click through everything.<\/p>\nOption three: retire<\/h2>\n
Side-by-side comparison<\/h2>\n
\n
The questions that decide it<\/h2>\n
\n
Why the first step is always inspection<\/h2>\n
Money tests the decision<\/h2>\n