The forecast stopped arriving
Every Monday a demand forecast, a churn list or a pricing recommendation used to land in someone's inbox. The data scientist who built it ran it themselves, from notebooks on their laptop, with a set of steps only they knew. They have now left. The Monday email has stopped.
You have found a folder of Jupyter notebooks with names like "final_v3_USE_THIS", a few CSV files and a note that says "run cells in order". Someone tried, and got errors about missing packages and files that no longer exist. The business had come to rely on those numbers, and now nobody can produce them.
Why models end up this way
A lone data scientist in a small team is usually asked for results, not infrastructure. They work in notebooks because notebooks are fast for exploring. Once something works, there is always a new question waiting, so the model never gets turned into proper software. The steps stay in their head, the data comes from exports on their machine, and the code depends on library versions installed months ago.
Nobody around them knows enough to ask for more, and they may not have had the time or remit to do it. It is not usually carelessness. It is a gap between building a model and running one, which one person in a small team rarely has time to cross.
What an orphaned model costs
| Situation | The effect |
|---|---|
| Outputs stop | Decisions go back to guesswork |
| Code on a personal laptop | Risk the work is lost entirely when the device is wiped |
| Unknown data sources | Nobody knows what the model was trained on |
| No documentation | Any successor starts by reverse-engineering |
| Hiring a replacement | Months before anyone is productive, and the same risk repeats |
There is also a trust question. If the old model cannot be reproduced, nobody can check whether its past outputs were right, which matters if decisions were made on them.
How we recover and rebuild it
- We secure everything we can find: notebooks, scripts, data files, model files, emails describing the outputs, and the laptop or cloud account if it is still available.
- We work out the data sources and the environment, including which library versions were used, and try to reproduce a past output exactly. Whether we can tells us how much of the original is recoverable.
- We write down what the model does in plain language: its inputs, how it was trained, what it predicts, and how the output was used.
- We rebuild it as a proper pipeline: code in a repository you own, data pulled directly from the source systems, a scheduled run on your cloud (AWS, Azure or Google Cloud), and outputs delivered where people use them.
- We add tests, monitoring for data problems and accuracy drift, and a simple way to retrain when needed.
- We hand over documentation and a walkthrough so a future hire, or your own analyst, can run and change it.
If reproduction shows the original was flawed, for example through data leakage that made results look better than they were, we tell you and recommend rebuilding from the requirement rather than preserving the mistake.
What you end up with
The Monday output is back, produced by a scheduled job rather than a person. The code, data connections and model live in accounts the business owns. There is a written description of what the model does and how to maintain it, and alerts if it starts to go wrong.
The next data hire inherits a working system to improve, not a mystery to decode.
And the business has a clearer view of what the model is worth. With past outputs reproduced and accuracy tracked, you can decide on evidence whether it deserves more investment, stays as it is, or should be retired.
Is this your situation?
- A data scientist or analyst built a model and has since left.
- The outputs have stopped or someone is struggling to produce them.
- The code is in notebooks with no clear instructions.
- Nobody is sure which data the model uses.
- You are about to hire a replacement and want to avoid the same problem.