Open source migration advisory for a clean move off a relicensed project.

A license change turns a settled dependency into an open question. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023, with the community fork OpenTofu. Redis moved to a dual model including the Server Side Public License as of March 2024, with the fork Valkey. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, with the fork OpenSearch. When the new terms restrict competitive use or carry distribution obligations you cannot accept, migration becomes a live decision. Open source migration advisory is how you make that decision with the cost and the risk in front of you rather than behind you.

Fork, alternative, or stay and pay

Migration is one of three routes, and the right answer is rarely obvious from the inside. A fork is often the lowest friction path because it preserves compatibility with what you already run, but it carries its own questions about long term support, governance, and the gap that can open between fork and upstream over time. A full alternative may be cleaner in license posture but heavier in engineering effort. Staying on the relicensed project under a negotiated commercial license is sometimes the cheapest option once the real numbers are on the table. The advisory weighs all three side by side so the path you take is chosen, not defaulted into.

Source available is not open source. The Business Source License and the Server Side Public License are not approved by the Open Source Initiative, and the practical exposure they create depends on how you deploy the software. A migration that does not first map that exposure can move effort without moving risk. We start with the map, then plan the move against it.

How the migration is sequenced

We sequence the work by risk and dependency, not by what is easiest to start. The components that carry the most exposure and the fewest blockers move first, so the risk curve bends down early. We validate compatibility before any cutover, keep a rollback path at each stage, and treat the migration as a series of reversible steps rather than one irreversible jump. The aim is a move that reduces exposure as it goes and never introduces a new failure mode to retire an old one. Production keeps running throughout.

The advisory connects to the wider program. It builds on our open source license risk services, sits inside the remediation and alternatives pillar, and draws on the relicensing analysis in our relicensing exposure guide. For the foundational frame, see the open source license risk pillar.

Why buyer side independence matters in a migration

We are paid only by you. We do not resell the fork, the alternative, or the commercial license, so we have no stake in which way the decision lands. That is what lets the recommendation be honest. A vendor wants you on a paid plan. A tool company wants you on its platform. The advisory wants the lowest total exposure for your situation, and it will tell you when that means staying put and negotiating rather than moving. The leverage that independence creates often pays for the engagement on its own.

What you receive

You leave with a migration plan that names the destination, sequences the work, costs each phase, and flags the dependencies that could trip a cutover. The options are weighed on engineering cost, license posture, and timeline, with the trade offs stated rather than buried. The plan is built to be defensible to engineering, finance, and the board at once, so the migration is approved on its merits and survives contact with reality. For how this has played out in practice, see our case studies.