Checklists exist because experts forget steps under pressure. Transfer learning is full of steps that are easy to skip and expensive to skip, so this article gives you a real working checklist, organized by phase, with a short reason attached to every item. Use it as a tool, not a read-once article.
This assumes you already understand what is transfer learning at a working level; if not, start with the Complete Guide to What Is Transfer Learning. What follows is the operational layer that sits on top of the concept.
The checklist is organized into five phases that follow the natural arc of a project: before you start, data preparation, during training, evaluation, and after you ship. The phases matter because doing the right thing at the wrong time, like checking for drift before you have a model, or splitting data after you have augmented it, is nearly as harmful as not doing it at all. Run each section at its proper moment rather than reading the whole thing once and trusting your memory under deadline pressure.
Run the relevant section before you start, while you train, and after you ship. Each unchecked box is a place projects commonly go wrong.
Before You Start
The decisions made here cap everything downstream, so spend real attention.
- Write one task sentence and one success metric. Without a number, you cannot tell done from not-done.
- Confirm transfer learning is the right approach. If you have abundant data and an unrelated task, from-scratch may win.
- Select a base model by domain proximity, not fame. Domain match sets the performance ceiling.
- Verify the base model's modality matches yours exactly. Text, image, and audio primitives do not cross over.
- Check licensing and usage terms of the base model. A model you cannot legally deploy is worthless.
Why Domain Proximity Leads the List
Because no later tuning fully recovers from a mismatched base. This is the most consequential and least reversible choice you make, a point our best practices hammer for good reason. Treat the items above as gates: do not proceed to data work until every one is checked, because every later hour you invest compounds on top of these foundational choices. A wrong base model means that all your downstream effort is building on sand.
Data Preparation
Clean data quietly determines whether your metrics mean anything.
- Split a validation and test set before any augmentation. Splitting late causes leakage and fake accuracy.
- Deduplicate across splits. Near-duplicates in train and validation inflate scores.
- For time-based data, split by time, not randomly. Random splits leak the future into training.
- Check class balance and plan for imbalance. A skewed dataset rewards lazy models with empty accuracy.
- Audit a sample of labels by hand. Mislabeled data caps performance and is invisible in aggregate metrics.
- Confirm the data reflects production conditions. A model learns the world you show it; a skewed sample teaches a skewed view that fails in the field.
- Write a one-page labeling guideline before labeling at scale. Consistent definitions prevent the silent label drift that caps performance.
During Training
This is where discipline beats cleverness.
- Establish a frozen feature-extraction baseline first. It tells you whether fine-tuning is even worth it.
- Fine-tune with a learning rate about ten times smaller than from-scratch. Aggressive updates erase pretrained knowledge.
- Unfreeze layers gradually, from last to first. Early layers hold general knowledge that rarely needs change.
- Watch training versus validation curves every epoch. A widening gap is your overfitting alarm.
- Stop when validation plateaus. Extra epochs add overfitting, not skill.
For the full sequential version of this phase, see our Step-by-Step Approach to What Is Transfer Learning.
Evaluation
Aggregate numbers lie; this section makes you confront the truth.
- Report per-class precision and recall, not just accuracy. Overall accuracy hides minority-class failure.
- Compare against a non-transfer control. It is the only reliable way to detect negative transfer.
- Evaluate once on a truly untouched test set. Every other number was influenced by your decisions.
- Inspect actual misclassifications. Patterns in errors reveal data and labeling problems metrics cannot.
- Sanity-check on a few hand-picked hard cases. Curated edge cases surface weaknesses that random sampling can miss.
After You Ship
A model is a snapshot; the world keeps moving.
- Log a sample of real production inputs and outcomes. You cannot detect drift you do not measure.
- Set a performance threshold that triggers re-fine-tuning. Decay is inevitable; plan the response.
- Keep the training pipeline reproducible. Retraining should be routine, not an excavation.
- Schedule periodic label collection for missed cases. Yesterday's edge cases are tomorrow's training data.
- Record the exact base model, settings, and data version you shipped. Future you will need them to reproduce or debug the model.
- Define a rollback plan before deploying. If the new model misbehaves, you want a tested path back to the previous one.
The failure modes this checklist guards against are catalogued in our 7 Common Mistakes with What Is Transfer Learning, and the whole thing fits inside the staged structure of our Framework for What Is Transfer Learning.
How to Actually Use This as a Tool
A checklist only works if you run it deliberately, not from memory. The practical habit is to copy the relevant section into your project tracker at the start of each phase and physically check items off as you clear them, rather than trusting yourself to remember. The whole value of a checklist is that it catches the step an expert skips under deadline pressure, and you are most likely to skip steps precisely when you are confident and rushed.
Two items deserve special vigilance because they are silent when violated. Data leakage and an absent frozen baseline both produce results that look fine, so nothing prompts you to revisit them. Build the habit of treating those two as non-negotiable gates: no training before the splits are clean, no fine-tuning before the baseline is recorded. If you enforce only those two with rigor and treat the rest as strong defaults, you will already avoid the majority of failures that sink real transfer learning projects.
Frequently Asked Questions
Which checklist item is most often skipped?
The frozen feature-extraction baseline. Teams rush to full fine-tuning and then cannot tell whether it actually helped. The baseline is fast, cheap, and the only honest reference point for judging fine-tuning's value.
Do I really need both a validation and a test set?
Yes. The validation set guides your decisions during training, which means it gets indirectly contaminated by those decisions. The test set, touched only once at the end, gives you an honest estimate of real-world performance that the validation set can no longer provide.
How do I check for data leakage practically?
Split your data before augmenting, deduplicate near-identical samples across splits, and for time-series data split chronologically. Then sanity-check by confirming no example or its close variant appears in more than one split. Leakage produces suspiciously high validation scores.
Is the after-ship section optional for a quick project?
It is the most commonly cut, but skipping it means your model silently decays with no warning. At minimum, log a sample of production data and set a performance threshold. Without that, you will only learn the model failed when a user complains.
Key Takeaways
- Decide the success metric and base model up front; domain proximity caps everything downstream.
- Split validation and test sets before augmentation and deduplicate to prevent data leakage.
- Always start with a frozen baseline, fine-tune with a conservative learning rate, and unfreeze gradually.
- Report per-class metrics and compare against a non-transfer control before trusting any result.
- Log production data, set a re-fine-tuning threshold, and keep the pipeline reproducible to survive drift.