Migrating from Lens and OpenLens in 2026

If you're still running Lens, you've probably noticed the ground shifting under you. The open-source repo no longer matches the commercial desktop product. Lens now requires an account, and organizations above the revenue or funding threshold need a paid plan - currently starting at $25 per user per month. The tool you adopted because it was a free, open desktop UI for Kubernetes is a different product now.

Nobody did anything wrong by picking Lens. It was the right call for years. But if you're reading this, you're probably deciding where to go next, and most "Lens alternatives" articles are written by vendors who conclude, surprisingly, that the answer is their product. We make one of the alternatives, so discount accordingly - but here's the map as we honestly see it.

Lens's licensing shift is the trigger for this decision, not the whole decision. Replacing Lens with another resource browser fixes the account and pricing problem, but not necessarily the operational gaps that made Kubernetes hard in the first place: understanding what connects to what, what changed before an incident, and where traffic is actually flowing.

TL;DR

• Want exactly the Lens desktop experience, still free? Freelens.
• Want a CNCF-governed, plugin-extensible dashboard? Headlamp.
• Live in the terminal? k9s, and you probably already know it.
• Want the capabilities we couldn't get from Lens forks or plugin-first dashboards - topology, persistent history, live traffic, GitOps, audit, and agent-ready context - in one no-login tool? That's why we built Radar.

Weighing every option line by line? We keep a full comparison of Lens alternatives and a detailed Radar vs Lens breakdown up to date separately. This post is the decision framework.

What actually happened to Lens

A quick timeline, because the fork situation confuses everyone:

• Mid-2022: Lens 6.0 introduces paid subscription requirements for commercial use.
• January 2023: Mirantis moves exec, logs, and shell into proprietary code in Lens 6.3. OpenLens builds lose core features, and community energy starts shifting to forks.
• June 2023: OpenLens publishes its last release. Its repository now says to expect no more updates because Lens closed its source code.
• Freelens emerges as the actively maintained community fork and becomes the real successor for people who want the Lens desktop experience.
• January 2024: the original lensapp/lens repo publishes its last GitHub release. Since then, the commercial Lens product and the OSS repo have diverged.
• Today: Lens is a commercial desktop product with mandatory login and per-seat pricing for organizations above the revenue threshold.

On OpenLens? Migrate now

OpenLens is unmaintained software running with powerful credentials against clusters whose API surfaces keep moving. That's the most urgent migration in this article. You do not need to move workloads or change cluster configuration - pick a replacement, point it at the same kubeconfig, and verify the workflows you used in OpenLens.

Option 1: Freelens - the "I just want my Lens back" path

Freelens is the actively developed fork, and it's good. Same desktop paradigm, same mental model, no login, no paywall. If your team's muscle memory is Lens-shaped and you want the smallest possible migration, this is the honest recommendation. Point it at your kubeconfig and you're done in minutes.

The tradeoff: it inherits Lens's architecture - an Electron desktop app doing client-side work against the API server, one kubeconfig per laptop. That was Lens's ceiling too. It browses resources well; it doesn't explain a cluster to you.

Option 2: Headlamp - the CNCF path

Headlamp is a CNCF Sandbox project under SIG UI, extensible through plugins, and shipping fast. If your organization weights foundation governance heavily, or you want to assemble a dashboard from plugins to your exact taste, it's a solid choice - and it runs in-cluster as a web app, not only on the desktop.

The tradeoff is the assembly itself: much of the depth arrives via plugins you select, install, and maintain, and the out-of-box experience is a resource browser. We ranked it honestly against everything else in our 2026 dashboard comparison.

Option 3: k9s - the terminal path

If you're a k9s person, you're not reading a migration guide. k9s is excellent - it's just answering a different question: fast keyboard-driven resource operations, not visual cluster understanding. Plenty of Radar users keep k9s open in the next pane. Coexist.

Option 4: Radar - the "understand the cluster" path

Radar exists because neither the Lens family nor plugin-first dashboards gave us the operational view we needed at Skyhook. We wanted one tool that understood the cluster as a connected system, covered the ecosystem we actually ran, and worked equally well for an engineer in the UI and an agent over MCP.

The result is a single Go binary, Apache 2.0, with no login, no account, and no agents to install. Run it locally against your kubeconfig, as a desktop app, or in-cluster as a web UI. Where Lens-style tools show you lists of resources, Radar's core is the relationships: a live topology with ownership chains (Deployment to ReplicaSet to Pods), an event timeline for "what broke first", service traffic, Helm release forensics, and a built-in audit that runs the checks you forgot. It auto-detects 120+ ecosystem CRDs as typed views and topology edges - plus any other CRD in your cluster - instead of asking you to assemble plugins.

Lens has MCP now, so the question is not "MCP or no MCP." It is whether the MCP is a thin kubectl-style bridge or a real cluster-understanding layer. Radar's built-in MCP server gives the agent topology, issues, timelines, relationships, scrubbed logs, and diagnosis tools instead of making it reconstruct the cluster from raw API output.

curl -fsSL https://get.radarhq.io | sh && kubectl radar

Or Homebrew (brew install skyhook-io/tap/radar), a desktop app, or Helm for in-cluster - all four on the homepage.

Radar's tradeoffs, honestly: multi-cluster fleet views live in Radar Cloud, a separate per-cluster-priced product - OSS Radar is one cluster at a time. And it's the youngest project on this list: weekly releases mean fast fixes, but also a tool that's still growing into some corners.

The migration itself

Whatever you pick, the actual migration is undramatic. None requires moving workloads or changing cluster configuration, and the local options read your existing kubeconfig:

1. Inventory what you actually used in Lens. Most teams: resource browsing, logs, exec, port-forward, maybe metrics. Everything on this page covers those.
2. Check your extensions. Lens extensions don't port anywhere. List what you depended on and find the equivalent - a Headlamp plugin, a Radar integration, or a standalone tool.
3. Run the new tool alongside Lens for a week. Nothing about this is one-way.
4. If you're on OpenLens, don't wait. Unmaintained software with cluster-admin credentials is not a neutral state.

Where this leaves you

The Lens story is a reminder to inspect a Kubernetes tool's governance, license, and escape hatches before you standardize on it. It is also a useful moment to decide whether you want continuity or a more capable operating model: Freelens if you want the familiar desktop workflow, Headlamp if you want foundation governance, k9s if you want the terminal, Radar if you want the cluster explained rather than listed.

Radar is open source and takes about two minutes to try against a real cluster: github.com/skyhook-io/radar. If it doesn't answer a question kubectl couldn't, delete the binary and keep the two minutes as a story.