For most major upgrades, yes. A short, timeboxed spike of two to three days turns a vague estimate into one grounded in your code. Try the upgrade on a branch, record what breaks, and stop at the timebox. The output is a plan and a size, not a merged change.
What a spike is for
Major upgrades hide their cost. Release notes list breaking changes in general, but not which ones hit your code. A spike answers a narrow question: how much work is this, here, for us?
It does not aim to finish. If the spike finishes the upgrade, treat that as a bonus and still write down what you learned.
When to run one
| Situation | Spike? |
|---|---|
| Patch or minor bump, tests pass | No, just merge it |
| Major bump with a migration guide and good tests | Short spike, one day |
| Major bump touching a core framework | Yes, two to three days |
| Several majors behind | Yes, and plan stepwise, see below |
If you are many majors behind, our guide to upgrading one major at a time pairs well with a spike for each step.
How to run it
- Set the timebox first. Write it in the ticket. Two or three days is typical. When it ends, you stop.
- Use a throwaway branch. Bump the dependency, install, and run the build.
- Run what exists. Unit tests, integration tests and a basic smoke test. Note what fails, and why.
- Search for deprecated APIs. Compiler warnings, linter rules or deprecation output show where your code uses removed features.
- Sample, do not fix everything. Fix one example of each class of failure to learn how hard the fix is.
- Check the ecosystem. Do the plugins and companion libraries you rely on support the new version? A single blocked plugin can set the schedule.
What to record
Keep the write-up short and structured:
- Number of failures, grouped by cause.
- One representative fix for each cause, with time taken.
- Blockers outside your control, such as an unsupported plugin.
- A revised estimate in small, medium or large, with a range.
- A recommendation: proceed, split into steps, defer, or replace the dependency.
What to decide afterwards
The spike should end with a decision someone can sign. Four outcomes are common:
- Proceed as planned. The estimate holds.
- Split. Break the work into smaller upgrades, each shippable. See major upgrades in small steps.
- Defer with a reason. The cost is high and the risk low this quarter. Put it on the deferred list.
- Replace. The dependency is the problem, not the version.
Guard against creep
Spikes grow when nobody stops them. Put a second person on the check-in at the halfway point. If the spike is already over budget, ask whether the surprise is the finding.
Where Safeguard fits
Safeguard's SBOM and dependency scanning shows which services use the library, so your spike can name every affected team up front. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a spike different from a proof of concept?
A spike answers a question about effort or feasibility and is thrown away. A proof of concept often becomes the start of the real work.
What if the spike fails outright?
A clear failure is a valid result. Record why, and use it to justify a replacement or a longer, stepwise plan.
Last reviewed: 19 October 2026.
