How to migrate an OptaPlanner application

Migrating a solver is not the hard part of migrating a solver-based application. This is the sequence we would run, and the order matters more than any individual step.

Before anything: pin the current behaviour

The first task is a regression harness, and skipping it is how these projects go wrong. Capture a set of real planning problems from production, with their inputs and the schedules the current system produced. Twenty is usually enough if they are chosen for variety: a normal week, a week with two sick crews, a week with a parts shortage, the week everyone remembers because it went badly.

Record the score breakdown, not just the assignment. You need to know which constraints were binding, because after migration the assignment will differ in harmless ways and you must be able to tell a harmless difference from a broken constraint. Without this harness, “is the new one as good as the old one” is answered by opinion.

Port the constraint model

The constraint model is the asset. It encodes years of argument with operations about what actually matters: that a job cannot be assigned to someone without the certification, that travel between two sites in one afternoon is possible in summer and not in winter, that a particular customer’s window is hard and everyone else’s is soft.

Port it constraint by constraint, running the harness after each one. Resist the temptation to improve the model while porting it. A migration that also fixes three long-standing modelling complaints cannot be validated, because you can no longer tell whether a difference is the migration or the improvement. Improve afterwards, on a supported stack, with the harness in place.

Deal with the data quality you find

Every migration of this kind surfaces the same thing: constraints that were quietly disabled because the data to evaluate them was never reliable. Someone commented out the certification check in 2023 because half the technicians had no certifications recorded, and it stayed out.

These are worth listing explicitly as findings rather than porting the workaround. Each one is a place where the schedule is worse than it looks, and where fixing the record is a bigger win than any solver change. If the list is long, the migration has told you something important: the engine was never the constraint.

Then decide about the application

With the solve on a supported engine and the harness green, look at what surrounds it. Often the solver was embedded in an application built at the same time, on a stack of the same vintage, with its own maintenance question. The scheduling piece was just the part with a name attached.

The honest options are to keep it, to modernise the surrounding application while keeping the solve, or to move the whole thing onto a maintained system of record and call the solver from there. Which is right depends on how much of the application is still doing useful work and how much is a UI nobody enjoys using.

What we do here

This is the work Raining Code does: modernising applications that have a good model trapped in an old stack. Where the answer is a new system of record for assets, work orders and workforce, Facterra is our product and we will say so plainly at the point we propose it. Where the answer is that your application is fine and only needs the engine swapped, that is a smaller piece of work and we will say that too.

If you have an asset, workforce or field-service application built on OptaPlanner and you are trying to work out what to do with it, we are glad to look at it with you.