Warm Starts Are More Than a Solver Trick | Learn

Most Production MILPs Do Not Start From Zero

A lot of optimization examples are built as if every solve appears out of nowhere. Load data. Build model. Call the solver. Wait for optimality.

Production systems usually have much more information than that.

You probably solved almost the same problem yesterday. You may have a plan currently being executed. You may have a heuristic that produces a decent feasible solution in milliseconds. You may know which facilities were open, which vendors received orders, which lanes were used, and which products were allocated scarce capacity. You may even have the incumbent from a previous solve with nearly identical data.

Throwing all of that away is often wasteful.

A warm start is commonly presented as a solver trick: give the MIP solver a feasible incumbent and maybe it solves faster. That is true, but it is the least interesting version of the idea.

In a repeated decision system, warm starts are part of the architecture. They connect yesterday’s decision to today’s optimization problem. Used well, they can improve runtime, solution quality under a time limit, and operational stability. Used badly, they can hide a weak formulation, preserve stale decisions, or create the illusion that the solver is doing better than it really is.

The practical question is not simply, “Should I use a MIP start?”

It is: What useful information from the previous decision cycle should survive into the next one?

Start With the Decision, Not the Solver Parameter

Suppose every morning you solve a replenishment MILP for products (i), vendors (v), and weeks (t).

A simplified model might include:

(q_{it}): order quantity for item (i) in period (t),
(y_{vt}): binary indicating whether vendor (v) receives an order,
(x_{it}): inventory or projected inventory state,
(z_{it}): shortage, expedite, transfer, or other recourse decisions.

You minimize expected purchasing, holding, shortage, freight, and activation costs subject to inventory balance, MOQ, pack-size, capacity, budget, and operational constraints.

Tomorrow, most of the structure is unchanged. One day of demand has arrived. Inventory changed. Forecasts moved. A supplier may have changed capacity. Some decisions from yesterday may now be committed.

That means yesterday’s solution is not just a random feasible point. It is information about a nearby decision problem.

Before touching the solver, ask:

Which decisions from the prior solve are already committed and therefore must become state or fixed constraints?
Which decisions are still editable and can be proposed as a starting solution?
Which variables have a natural mapping from yesterday’s horizon to today’s horizon?
Which parts of the old solution are invalid because the world changed?
Can a fast repair heuristic turn the old plan into a feasible plan for the new model?

Those questions matter more than whether the solver API calls the feature a MIP start, start vector, incumbent, or warm start.

The Simplest Warm Start: Shift Yesterday’s Plan

Consider a 12-week rolling-horizon model solved every week.

Yesterday’s plan was

[ q^_{i,1}, q^{i,2}, \ldots, q^*{i,12}. ]

After week 1 passes, a natural candidate for the next solve is

[ \hat q_{i,t}=q^*_{i,t+1}, \qquad t=1,\ldots,11. ]

You then construct a reasonable value for the new twelfth period.

For binary setup variables, lane selections, sourcing choices, or facility activations, the same idea applies. Shift the still-relevant decisions forward and use them as the initial candidate.

This is almost embarrassingly simple. It can also be very effective when consecutive planning problems are similar.

But there is an immediate problem: the shifted solution may no longer be feasible.

Demand may have been higher than expected. Inventory may be lower. Vendor capacity may have changed. An MOQ may now be violated. A lane may be unavailable. The old solution can be structurally useful while still being infeasible in the new state.

That is where production warm starts become interesting.

Suppose yesterday you planned to order 80 units from a vendor with an MOQ of 100 units. That was fine because another SKU contributed 40 units and the vendor-level order totaled 120.

Today that second SKU no longer needs an order. Blindly shifting the first SKU’s quantity gives an infeasible vendor order of 80.

A repair heuristic can make an explicit economic choice:

increase the first SKU to 100,
add another useful SKU to the order,
cancel the vendor order,
move demand to another source,
or accept a modeled shortage if that is cheaper.

The repair does not need to be globally optimal. Its job is to produce a credible feasible incumbent quickly.

This is an important distinction. A heuristic used as a warm start does not compete with the MILP solver. It gives the solver a head start.

In many real systems, the architecture can be:

state -> previous plan -> repair heuristic -> feasible incumbent -> MILP improvement -> executable decision

That is often more useful than debating whether the heuristic or MILP should “win.”

Why a Good Incumbent Helps

For a minimization problem, once the solver has a feasible incumbent with objective value (U), it can prune any branch-and-bound node whose lower bound cannot beat (U).

A better incumbent can therefore reduce the search tree.

More importantly, production models frequently run under hard time limits. If you have 60 seconds, the business does not care that the solver would have proven optimality after 14 minutes. It cares about the best executable decision available at second 60.

This changes the metric.

Instead of only measuring time to proven optimality, measure the incumbent trajectory:

[ U(1), U(5), U(10), U(30), U(60). ]

A warm start may barely change time to proof but dramatically improve the solution available after five seconds. In an online or batch decision system, that can be the economically relevant result.

Do Not Confuse Warm Starts With Fixing Decisions

This mistake is common.

A MIP start says, roughly, “Here is a candidate solution. Use it if it helps.”

Fixing a variable says, “You are not allowed to choose anything else.”

Those are completely different modeling decisions.

If yesterday’s sourcing decision was (y_v=1), using (y_v=1) as a start leaves the solver free to switch it off. Fixing (y_v=1) removes that choice.

Only fix a prior decision when the business has actually committed to it or when you deliberately impose a freeze rule. Do not convert historical plans into constraints merely because they are convenient.

This distinction is especially important in supply chain systems, where purchase orders, production releases, bookings, and transfers become committed at different times.

The model state should represent what is irreversible. The warm start should represent what is plausible.

Partial Starts Can Be Better Than Fake Precision

You may not have a trustworthy value for every variable.

That is fine.

If the structural binary decisions are stable but continuous quantities need to be recomputed, start the binaries. If yesterday’s sourcing pattern is informative but inventory balance variables are derived, provide the sourcing choices and let the solver fill in the rest when the solver supports partial starts.

Do not manufacture values merely to populate every variable.

For a large model, the highest-value information may be concentrated in a small number of difficult discrete decisions:

which suppliers are activated,
which facilities open,
which trucks are used,
which orders cross an MOQ threshold,
which products receive scarce capacity,
which production sequences or assignments are selected.

Those choices define much of the combinatorial structure. A partial start that gets them mostly right can be more useful than a full but poor solution.

Warm Starts and Uncertainty

Warm starts become even more useful when the optimization model sits inside a stochastic or simulation-based policy.

Suppose you evaluate hundreds of demand scenarios. The scenarios differ, but the underlying state, product network, and cost structure are shared. Or suppose you repeatedly solve similar deterministic subproblems inside a decomposition or simulation loop.

The solution to one nearby problem may be useful for the next.

But similarity has to be earned, not assumed.

If scenario A has normal demand and scenario B contains a severe supplier outage, forcing the search to cling to A’s structure may add little value. If a new forecast changes only a few SKUs, reuse is much more plausible.

A practical system should track how far the new problem moved. Useful signals include:

change in inventory position,
change in forecast or sampled demand,
newly active or inactive constraints,
capacity changes,
cost changes,
number of prior decisions that remain feasible,
objective value of the repaired incumbent.

Warm-start performance can then be analyzed as a function of problem distance rather than treated as magic.

The Previous Solution Is Also a Debugging Tool

There is another benefit that gets less attention.

If yesterday’s plan was feasible and today’s nearly identical model rejects the shifted plan, ask why.

That difference can expose:

a bad data feed,
a unit conversion error,
a new constraint that unexpectedly became binding,
an incorrect horizon mapping,
a commitment-state bug,
or a genuine business change.

The feasibility failure itself is information.

For repeated models, I like logging the result of attempting to reconstruct or repair the previous solution before the main solve. It creates a useful diagnostic layer between raw input validation and solver logs.

You are no longer asking only, “Did today’s model solve?”

You can ask, “Why did yesterday’s executable plan stop being executable today?”

That is a much better production question.

A Warm Start Does Not Rescue a Bad Formulation

There is a dangerous success mode here.

Imagine a weak MILP formulation that struggles badly from scratch. You provide a strong incumbent and suddenly the model meets its runtime SLA.

Great. Ship it if it solves the business problem.

But do not conclude that the formulation is healthy.

A warm start can improve the primal side of the search while the lower bound remains terrible. You may get a good solution quickly but still have a large gap and a huge tree because the relaxation is weak.

Track both sides:

incumbent objective,
best bound,
MIP gap,
nodes explored,
time to first feasible solution,
time to target-quality solution,
time to proof if proof matters.

If the start gives you an excellent incumbent at second zero but the bound barely moves, formulation work may still have enormous value.

Warm starts and strong formulations are complements, not substitutes.

Benchmark Them Properly

Do not test one instance and declare victory.

Build a representative benchmark set containing normal days and ugly days:

low and high demand,
tight and loose capacity,
small and large vendor portfolios,
MOQ-heavy cases,
disruption cases,
cases with substantial forecast movement,
cases where yesterday’s plan is nearly unchanged.

For each instance, compare at least:

cold solve,
previous-solution start,
repaired previous-solution start,
fast domain heuristic start, if available.

Then record metrics at the actual production time limit.

The main metrics should include:

feasible-start acceptance rate,
repair time,
time to first feasible solution,
objective at fixed checkpoints,
final objective at the time limit,
best bound and gap,
node count,
total end-to-end latency,
decision changes versus the prior executable plan,
realized or simulated downstream economic performance.

That last metric matters. A numerically better objective in the planning model is not automatically a better policy if the objective is only an approximation of the real economics.

Stability Can Be a Benefit, but Do Not Get It for Free

Starting from yesterday’s solution often makes the new solution look similar to yesterday’s solution. Operational teams may love this because the plan stops thrashing.

Be careful.

If stability has real economic value, model it. Add change costs, commitment rules, or explicit penalties for unnecessary plan movement.

Do not rely on solver path dependence as your stability policy.

A warm start should accelerate the search. It should not secretly define the business preference.

If two solutions are economically equivalent and one changes fewer decisions, encode that preference deliberately through a secondary objective or stability cost. Then the behavior is explainable and testable.

Implementation Notes That Matter

Warm starts fail in boring ways.

Variable identities change between runs. Product IDs disappear. Horizon indices shift incorrectly. A start uses rounded quantities that violate pack constraints. A binary activation variable disagrees with the quantity variables beneath it. A model rebuild changes variable ordering and the application maps values by position instead of semantic key.

Do not map starts by array position unless the mapping is guaranteed by construction.

Use stable business keys such as

[ (\text{vendor},\text{SKU},\text{location},\text{period},\text{decision type}). ]

Validate the candidate before sending it to the solver. Check obvious domains, commitments, pack sizes, and high-level balances. Log how many variables mapped successfully and how many were dropped.

Also measure warm-start preparation time. Spending 45 seconds building a start to save 20 seconds of solver time is not an optimization.

Failure Modes I Would Expect in Practice

The old solution is stale. The state changed enough that reuse adds little value. Detect this and fall back gracefully.

The start is infeasible. Repair it or provide a trustworthy partial start. Do not assume the solver will magically understand your business intent.

The heuristic is too expensive. A warm-start generator should usually be cheap relative to the optimization it accelerates.

The team reports only solve time. A start may change time to good incumbent, time to proof, and end-to-end latency differently. Log all three.

Historical decisions become accidental constraints. Keep commitment logic separate from candidate-solution logic.

The warm start masks formulation weakness. Inspect bounds and gaps, not only incumbents.

The solver ignores the start. That can happen. Verify acceptance and benchmark behavior rather than assuming the API call helped.

The start creates fake stability. If stability matters, put it in the objective or constraints explicitly.

What I Would Build

For a repeated supply chain MILP, I would make warm-start handling a first-class component of the decision pipeline.

Store the prior executable decision with stable business keys and the state under which it was produced. When the next cycle begins, separate committed actions from editable actions. Shift the editable plan into the new horizon, remove decisions that no longer exist, and run a cheap feasibility repair. Validate the candidate and pass it to the solver.

Then log what happened.

Was the start feasible? How much repair was required? What was its objective? How quickly did the solver improve it? Did it improve the solution available at the production time limit? How different was the final decision? Did those changes improve simulated or realized economics?

Over time, you can learn when warm starts are valuable and when the problem has moved too far for yesterday’s plan to matter.

That is the broader lesson.

Optimization in production is rarely a sequence of unrelated mathematical programs. It is a sequence of decisions made as the state of the world evolves.

Your solver does not have to forget everything between those decisions.