What happens when OptaPlanner support ends

If a scheduling or routing application in your estate runs on OptaPlanner, someone has probably already asked what happens now that its original creators have moved on to a commercially maintained successor and the open-source line is receiving less attention than it used to. This is a practical answer, aimed at whoever owns that application.

What does not change

The code you have deployed keeps working. OptaPlanner is Apache 2.0, the last mature releases are on Maven Central, and a solver that returns a feasible roster today will return the same roster next year. There is no licence expiry, no phone-home, no switch anyone can throw. Anyone telling you the software stops is selling something.

What does change

Four things, in roughly the order they will bite.

Security patches. The solver itself has a small attack surface, but it sits on a stack that does not: Java, the framework it is embedded in, the serialisation libraries around it. When a CVE lands on that stack, the question is who backports the fix. On an unmaintained line, the answer is you.

Platform compatibility. Your infrastructure team will move to a new Java LTS on their own schedule. A library that is no longer tracking new Java and framework releases becomes the reason an application is pinned to an old runtime, and pinned applications become migration projects on someone else’s timetable.

Expertise supply. Constraint-solver work is specialist. The people who understand score corruption, shadow variables and construction heuristics are increasingly working on commercially supported forks. Hiring for an unmaintained line gets harder every year, and the person who wrote your constraint model has usually left.

Nobody to call. This is the one that matters most and shows up least in a risk register. When a solve that has run for three years starts returning infeasible results after a data change, an unsupported dependency means the answer has to be found in-house, under pressure, by someone reading someone else’s ConstraintProvider.

Four options

Do nothing, deliberately. Legitimate for an application with a known end-of-life, a stable constraint model and no compliance exposure. Write down the decision and the date you will revisit it, otherwise it is not a decision.

Fork and self-maintain. The licence permits it, and for a team with platform engineers and a genuinely unusual constraint model this can be right. Budget it honestly: someone has to own solver internals, not just call the API.

Move to a commercially supported fork. The direct path. Same lineage, same concepts, maintained and supported by many of the people who built the original. The migration is real work but it is the shortest distance between where you are and a supported stack.

Replace the engine entirely. Usually the most expensive option, because the value in a scheduling system is rarely the solver. It is the constraint model that took two years and four arguments with operations to get right, and that model is what you re-derive when you change engines.

The question that decides it

Before choosing, find out where the pain actually is. Ask the people who use the schedule how much of it survives to Friday. If the answer is “most of it”, you have a solver problem and the four options above are the whole decision. If the answer is “the planner rebuilds half of it by Tuesday”, the solver was never the problem, and swapping it will produce a differently-optimal schedule that the planner still overrides. We wrote about that failure mode separately, in why workforce optimisation fails before the algorithm runs.

Facterra is not a solver and we do not sell one. We build the asset, work-order and workforce records that a solver has to be fed, and we integrate the engine rather than competing with it. If you own an asset, workforce or field-service application built on OptaPlanner and the question on your desk is what to do with it, we are happy to be a second opinion on the assessment. That conversation is free and does not end in a Facterra licence unless you want it to.