The Temporary Solution That Turned Fifteen
Every IT environment has at least one. You know which one it is without thinking about it for more than a second, because it has been in the back of your mind since you inherited the environment, a quiet operational hum of something that was never supposed to be permanent becoming more permanent with every passing quarter. The script that was written over a weekend to solve an urgent problem and was supposed to be replaced by a proper solution within three months. The manual approval process that was implemented as a bridge while the new system was being selected, and is now the system. The shared drive folder that was set up as a temporary document repository until the intranet was built, and has grown to thirty-seven thousand files organized by a logic that made sense to someone in 2011.
Temporary solutions survive because they work, which is their first virtue and their deepest trap. The weekend script processes the data correctly every time it runs, which means there is never a moment of visible failure that creates urgency for replacement. The manual approval process has become so familiar to everyone involved that the friction is no longer perceived as friction but as the natural texture of the workflow. The shared drive folder is navigated by institutional knowledge that has been transferred through osmosis to every new team member, a kind of oral tradition of folder structure that would collapse immediately if the two people who actually know it left the organization. All of these things are working, in the sense that the output is being produced and nobody is filing a ticket about it. None of them are working in the sense that they represent a sustainable, documented, transferable operational approach.
The hidden cost of the temporary permanent solution is not the solution itself. It is everything that cannot be built on top of it. The automation you cannot trigger because the data is in a format that only the weekend script understands. The integration you cannot complete because the manual approval process has no API surface. The search capability you cannot implement because the shared drive folder structure is a human navigation system rather than a data architecture. Each temporary solution becomes load-bearing infrastructure without ever being designed for that purpose, and load-bearing infrastructure cannot be easily replaced because replacement requires understanding every dependency it has accumulated in the years it was supposed to be temporary.
The path out is not dramatic. It is incremental, documented, and unglamorous. It starts with an honest inventory of the temporary solutions in your environment, which requires asking the team members who have been there longest, because the temporary solutions are usually invisible in the official documentation precisely because they were never supposed to be documented officially. It continues with an impact assessment: what depends on this, what breaks if it is removed, and what would the replacement need to deliver? It ends with a prioritized replacement roadmap that treats these solutions with the same engineering rigor they were never given originally. Not because the replacement is urgent in the incident response sense. Because every day the temporary solution runs is another day the organization is building on a foundation it does not fully understand.
If it is still running fifteen years later, it was never temporary. It was just infrastructure that nobody was willing to call infrastructure. Call it infrastructure. Then fix it properly.
