When does a temporary workaround need to be treated as production?

Once people depend on it, treat it as production, even if replacing it is not currently funded. Write down what it does, who owns it, what it depends on, how to tell when it fails, and how to recover. That does not mean the workaround is good enough forever. It means the business should not be relying on invisible knowledge.

Then give the replacement a named owner, a scope, and a decision date. If there is no time or budget for that, make the choice explicit instead of letting the risk sit in the background.

I would start by asking what outcome the workaround is actually providing. A spreadsheet may be the report leadership trusts, not merely a clumsy substitute for a dashboard. If so, rebuilding the dashboard without changing that expectation will not retire the spreadsheet.

Map the whole process, including who supplies each field, how errors get caught, and who uses the result. Then either fix the process around the desired output or automate it in a way that preserves the checks people rely on.

Before replacing anything, capture a few known-good outputs and test the awkward cases. These tools often encode exceptions nobody remembered to document. A rewrite can look cleaner and still quietly change the numbers or break an old integration.

For a script, that might mean putting it under version control, adding basic checks, logging what it changed, and testing it against saved inputs. Those steps make the current process safer while you work out whether a full replacement is worth it.

There is no shame in keeping an ugly tool that is reliable enough for the job, but give it a real owner and a review date. “Temporary” with no end date can turn into permanent production without anyone making that decision.

At the review, check whether the risk, maintenance effort, or business impact justifies replacement. If not, keep supporting it deliberately and revisit later.