If your Eclipse RCP application is still business-critical in 2026, the uncomfortable question is no longer whether it still works. It is how long it is feasible to depend on an aging technology stack, a shrinking pool of engineers with deep RCP expertise, and a platform increasingly distant from how modern tools are built. Eclipse RCP is still maintained, and many applications will keep running for years. But that is exactly what makes migration easy to postpone, until user expectations or an external constraint sets the timeline for you.

That makes migration a strategic timing decision, not an emergency response: one that is easier to make well today than it may be in a few years.

We wrote about the long-term strategic position of Eclipse RCP last year: the platform remains viable, but the pool of engineers who know SWT, JFace, and OSGi well is shrinking, and the gap between RCP’s architectural assumptions and what users now expect from tooling, web delivery, collaboration, and AI-native workflows keeps growing. Nothing about that has reversed in the past year. If you want first-class AI-native development capabilities in an RCP-based product today, you largely have to build that integration yourself.

What has changed since our 2025 migration guide is the other half of the equation: the cost of doing the migration work itself. AI-assisted development has become effective at implementation-heavy parts of a re-architecture, including codebase analysis, test generation, business logic extraction, and UI reimplementation. As a result, migrations many organizations shelved as too expensive or too risky deserve a second look.

In this article, we look at how AI has changed the migration calculus. Migration has not become easy in some general sense, but a specific, large share of the work it always required now takes substantially less implementation effort.

Staying on RCP can still be a rational decision for a stable application with a limited remaining lifetime, predictable requirements, and secured maintenance expertise. But if the tool is expected to evolve for another five or ten years, attract a new audience and grow its market share, having no migration strategy is a much harder position to defend.

The best time to migrate is while you still control the timeline.

Start with the part AI didn’t change: migrating off Eclipse RCP is not an upgrade. It’s a re-architecture.

Moving from SWT/JFace to a modern web UI, from OSGi to a different module system, from the workbench’s extension points to current state-of-the-art application platforms, changes assumptions your application has relied on for years. Some business logic can survive the transition. The UI, the extension mechanism, the deployment model, and often the workflows themselves usually can’t.

AI acceleration does not turn migration into a mechanical conversion. An AI coding agent can translate a lot of code, but it can’t tell you whether a given extension point encodes a business rule or an architectural accident, and it can’t judge the trade-offs of mapping a certain existing implementation to a new paradigm, and which parts of your workbench configuration even deserve to survive in the new product. Important behavior in an RCP application hides in plugin manifests, extension points, Eclipse platform behavior, OSGi services, product and launch configuration, not just in Java source. Reading that correctly is still an engineering and domain judgment, made by people who understand both the old system and the new one.

AI changes how fast the work gets done. It doesn’t change who decides what the work should produce.

The biggest change since our 2025 guide is where AI now saves real implementation effort. Rather than saying “AI makes migration faster” in the abstract, the useful question is where it makes a concrete difference.

Understanding the existing codebase. AI can explore a large, unfamiliar RCP codebase fast: tracing dependencies, mapping which plugins talk to which extension points, spotting duplicated code and potentially unused implementation paths, and producing a first-draft feature inventory. That initial orientation used to consume substantial senior engineering time. AI can now produce a useful first map much earlier in the process. The catch is that architecture hypotheses generated this way still need validation from someone who understands RCP and the domain. Treat the output as a draft map, not ground truth.

Capturing existing behavior before you touch it. Characterization tests, tests that pin down what a component actually does today, are much faster to generate with AI than to write by hand, and they’re a real safety net during extraction and rewrite work. But a generated test faithfully encodes whatever the code currently does, bugs, dead workflows, and accidental implementation details included. Someone who knows the domain still has to decide which of those behaviors are actually a contract worth preserving.

Pulling business logic out from under the UI. Separating domain logic from SWT/JFace and OSGi, then wrapping it in a CLI, a service boundary, or another clean interface, is exactly the kind of pattern-heavy, well-scoped work AI-assisted development handles well. It makes implementing that boundary, once you’ve decided where it goes, considerably cheaper. It doesn’t pick the boundary for you.

Rebuilding the UI. SWT/JFace to modern web UI is often pattern-heavy implementation work, and it’s one of the areas where AI coding speeds things up the most. Don’t take that as license to recreate your desktop UI widget for widget. Migration is usually the right moment to rethink workflow, navigation, and review UX, not just port controls. Once you know what the new UI should actually do, AI can accelerate building it.

Everything repetitive in between. Adapters, boilerplate, mechanical refactors, migration scripts, repetitive configuration updates, documentation. None of this is glamorous, and all of it used to eat weeks of a migration project. AI can now handle a meaningful share of it.

Across all five of these, review stays non-negotiable. AI compresses implementation time. It doesn’t compress the judgment calls. We wrote about how that split plays out across our own projects, RCP modernization included, in AI (Coding) at EclipseSource: The Internal Story. The short version: with AI, we execute RCP migrations dramatically more efficiently, but only because the team doing the work has two decades of RCP expertise behind it, not instead of it.

AI changes the migration economics, not the need for migration expertise.

Before any of that acceleration matters, decide what’s actually worth migrating. A migration is a rare chance to look at your application and ask, honestly, which capabilities still earn their keep.

Mature RCP applications accumulate features, workflows, and implementation paths over years. Some of that is essential. Some of it is a workflow that mattered years ago and sees little or no use today. You won’t know which is which until you look, and AI-assisted codebase exploration makes the technical inventory far cheaper to build than it used to be: which features exist, how they are implemented, what they depend on, and where usage data or stakeholder input is needed to judge their actual value.

The decision for each capability is still a human one: keep it as-is, extract and reuse it, reimplement it, redesign it, merge it into another workflow, or retire it. A simple table connecting workflow, current implementation, actual usage, reuse decision, and target implementation is usually enough to run this exercise. It doesn’t need to become a heavyweight methodology to be useful.

There is a second question worth asking at the same time: is the workflow itself still the right one? Most RCP workflows were designed when every step was manual. If an agent can take over some of those steps today, the workflow you should build in the new product may no longer be the one you have. Our 2026 build guide goes into this in detail, including why starting from the existing workflow and testing step by step what AI can actually take over usually works better than committing to a full AI-native redesign up front.

The fastest feature to migrate is the one you decide you no longer need.

Our 2025 guide leaned hard into reuse, for good reason: reimplementing something was expensive and risky, so preserving working code, even awkward working code, often paid off; or at least unblocked the migration so it can be incrementally improved later. That is no longer automatically true.

Shopify recently described a similar shift in mobile development: coding agents changed the economics enough for the company to revisit its earlier React Native decision and move back toward separate native implementations in Swift and Kotlin. We observe similar dynamics with porting tool implementations to a different tech stack, for instance with EMF-based modeling tools. Rather than wrapping the model processors in some compatability layer it is now in many cases better to extract the data structures and rules into requirements that are re-implemented on a modern stack with AI.

Reuse is still valuable, especially for proven, high-value domain logic with clear input-output boundaries: compilers, parsers, generators, analyzers, validators, simulation engines, anything encoding years of accumulated domain correctness that doesn’t add clunky runtime dependencies if reused. Don’t rewrite that just because you can.

But reuse shouldn’t be a goal on its own. If keeping a component means carrying forward OSGi coupling, SWT/JFace assumptions, an awkward legacy API, or an expensive bridge layer just to avoid reimplementing it, that trade-off looks different than it did two years ago. AI-assisted reimplementation has gotten cheap enough that rebuilding a mediocre component cleanly can now be more attractive than dragging its legacy baggage into your new architecture. Reuse can also carry technology heterogeneity into the new product. Keeping Java components alongside a primarily TypeScript-based architecture, for example, may be entirely justified, but it can add ongoing integration, build, deployment, and skills complexity. The recommendation is to evaluate reuse component by component, not as a blanket strategy in either direction.

Two patterns from our earlier guide still hold, and are worth carrying forward with that updated calculus in mind:

Extract headless business logic. Pull domain logic, generators, compilers, analyzers, validators, simulation code, out from under the UI and expose it through a CLI, a service boundary, or another clean, interoperable interface. The same capability can then serve the existing RCP product, the new product, automated workflows, and potentially AI agents, all from one implementation. AI reduces the effort of finding the boundary, writing the adapters, and generating tests around the extracted piece. The boundary itself is still an architectural decision.

Backport modern functionality into Eclipse. Embedding a web UI inside Eclipse, running GLSP-based diagram editors in both environments, or moving a DSL to the Language Server Protocol so the same language support works in old and new products at once, all reduce double implementation during the transition. Bridge layers deserve a fresh look too: a bridge layer that made sense when a full rewrite took six months may not clear the bar once AI-assisted reimplementation cuts that estimate substantially. It’s still case by case, not automatic.

Reuse what is valuable, not what is merely expensive to rewrite.

Most serious migrations go through a period where the old RCP product is still in production, the new product is being built, and some capability lives in both. This is where migrations stall, and it’s still one of the most consequential parts of the project.

The questions don’t change with AI: where do new features go? Which fixes need to land in both products? Which capabilities can be single-sourced through the extraction and backporting patterns above? How do you allocate teams without the group still maintaining the old tool feeling like the “legacy crew”? How do you move users over without burning their trust?

What’s new in 2026 is that AI-assisted development can increase velocity on both sides of that coexistence: the migration work and the ongoing maintenance of the legacy product. That can shorten how long the dual-tool phase needs to last. That matters, because this phase is expensive: you’re maintaining two products in parallel, often without anything close to two full product budgets.

Don’t expect that shortening automatically. The duration of a dual-tool phase is usually set by things AI doesn’t touch: how fast users can validate the new product, what a regulator requires before sign-off, how a release cycle is structured, how much resistance a workflow change meets internally. AI can compress the engineering side of coexistence. It can’t compress a user acceptance process or a compliance review.

The plan matters more than the acceleration. An explicit, communicated migration plan, covering phases, priorities, and timelines, kept up to date as it evolves, is still what turns “temporary” dual maintenance into an actual transition instead of a permanent state.

AI can shorten the dual-tool phase, but it cannot remove the need to plan it.

Where you migrate to depends on your requirements more than on any general ranking we could give here. VS Code-based approaches, Eclipse Theia, a custom web application, or another modern framework are all live options, and none of them is the default answer for every project. Our 2026 build guide covers the platform decision, foundation selection, PoCs, and team composition in depth, so we won’t repeat that here.

A web-based technology stack doesn’t mean your product has to become a browser or cloud application. Modern web stacks still ship as capable desktop applications, through Electron, Tauri, or similar.

Migration is also a chance to avoid rebuilding the exact tool you already have. Designing for humans and AI agents as two distinct kinds of users, exposing headless capabilities, building review-centric UX for AI-assisted workflows: all of this is easier to build in from day one of a new architecture than to retrofit into RCP later. The build guide goes deep on all of it. Treat this article as the place to plan the transition, and that one as the place to plan the target.

A migration like this benefits from three kinds of experience at the same time: legacy Eclipse RCP architecture, modern tool architectures, and practical knowledge of where AI can safely accelerate the work.

We’ve spent close to two decades in the Eclipse RCP ecosystem and, for more than a decade, built modern web-based tools alongside it. Combined with the AI-coding practice described in our internal AI-coding story, that is the combination we bring to migration projects.

Getting the full benefit from AI-assisted migration also depends on how the project is structured. We use clear specifications and context, small verifiable steps, and fast feedback loops appropriate to the part being migrated. Depending on the case, that can mean characterization tests, domain-level tests, reference data, automated UI validation, or giving an agent controlled access to the existing application so it can compare behavior directly. The right approach depends on whether a capability is being preserved, reimplemented, or deliberately redesigned.

In practice, that support covers migration assessment and feature rationalization, architecture and reuse-versus-reimplementation analysis, roadmap planning, proofs of concept, AI-assisted implementation, UX modernization, and dual-tool strategy, delivered through consulting, training, or hands-on implementation, depending on what your team needs most.

If you are considering a migration, our Eclipse RCP migration and support offering describes our migration strategy workshops, PoCs, implementation support, and other engagement options in more detail. If you want to start by defining the architecture and migration roadmap, see our migration workshop packages and indicative pricing.

Your RCP application may keep working for years. Your migration options may not stay equally good.

Your RCP application probably isn’t going to stop working next quarter. It might run fine for years. That’s exactly why you still have the freedom to migrate on your own terms, instead of on a timeline forced by a security patch, an OS change, or a maintainer who retires with knowledge nobody wrote down.

AI has changed what that migration costs to execute. The implementation-heavy parts are genuinely faster now: codebase analysis, testing, extraction, UI rebuilding, repetitive work. The judgment calls have not changed. Deciding what to keep, what to rebuild, and where the new boundaries go still requires the same expertise as before.

Waiting for an external trigger to force the decision is usually a worse position than migrating while you still control the timeline. If your RCP application is expected to matter for years to come, this is a good moment to revisit the plan.

👉 Explore our Eclipse RCP migration and support services

👉 Our service offerings for building custom tools and IDEs

👉 Our service offerings for building web- and cloud-based tools

👉 Our service offerings for AI-powered tools and IDEs

👉 Get in touch with us to talk about your migration

💼 Follow us: EclipseSource on LinkedIn

🎥 Subscribe to our YouTube channel: EclipseSource on YouTube