Migrating Eclipse and RCP Tools to the Web

Over almost two decades, the Eclipse Platform and Eclipse RCP have powered countless mission-critical tools and IDEs. But as outlined in our recent article on the future of Eclipse RCP, the technology landscape has shifted decisively toward modern, web-based architectures.

Migrating existing tools and IDEs from Eclipse RCP or the Eclipse Tools Platform to the web is not just a technical transition—it’s a strategic opportunity. The web stack has matured to the point where complex, domain-specific tools can thrive across browsers, desktops, and cloud environments. Now is the ideal moment to plan this journey while talent, expertise, and time are still on your side.

At EclipseSource, we’ve supported many successful migrations. In this post, we’ll share a high-level overview of best practices and a strategic approach to guide your transition—without diving into every detail here, but linking to additional resources for deeper exploration.

Strategic Migration: More Than Just a Technical Shift

A migration from Eclipse RCP or the Eclipse Tools Platform to a web-based platform is much more than simply changing technology stacks. It’s a strategic opportunity to reimagine your entire user experience, optimize and modernize your architecture, and introduce powerful new features that leverage cloud infrastructure, collaboration capabilities, and even artificial intelligence.

This transition also creates the perfect moment to simplify your toolset by removing outdated or rarely used features, cutting down on unnecessary complexity and reducing long-term maintenance overhead. By shedding unused components, your migrated application can become leaner, more maintainable, and better aligned with current user needs.

Equally important is the opportunity to rethink workflows in the light of AI. With modern AI-assisted development and analysis tools, everyday tasks can be streamlined, insights can be surfaced automatically, and automation can be embedded directly into the workflow—creating a more intelligent and adaptive user experience.

Instead of treating migration purely as a technical exercise, approaching it strategically ensures your tool or IDE stays relevant, responsive to evolving user expectations, and flexible enough to support emerging use cases. Let’s look at how to approach this journey effectively.

Get Familiar with Web-Based Tools

Before diving into the migration process, it’s essential for tool builders to get familiar with the modern technology stack and ecosystem. Understanding the underlying concepts, frameworks, and deployment options will help you make informed decisions during your migration.

For a comprehensive starting point, we recommend reading these two articles:

👉 How to Build a Custom IDE or Tool — While focused on building from scratch, this guide is up-to-date and provides valuable insights into modern architecture, frameworks, and best practices.

👉 Modern Web-Based Tool and IDE: Definitions, Concepts, and Architecture — A deep dive into the concepts, components, and architectural principles that underpin web-based tools.

These resources will give you a solid foundation before you begin evaluating migration paths.

Understanding the Realities of Migrating Eclipse Applications to the Web

It’s important to clarify some commonly misunderstood aspects of moving Eclipse RCP or Eclipse-based tools to a web-based stack:

This Is Not Just an Upgrade

Migrating to a web-based platform—even if it’s the next-generation Eclipse platform like Theia—is not comparable to upgrading to a newer Eclipse version. It often involves a complete rewrite of your application on a fundamentally different technology stack. While certain components can be preserved or reused, the migration should be viewed as a re-architecture rather than a version bump.

UI Code Must Be Rewritten

Any UI built with SWT, JFace, or related desktop UI technologies will need to be entirely re-implemented using modern web frameworks like React, Angular, or Vue.js. Although core business logic can sometimes be reused, many teams also take this opportunity to shed Java and OSGi in favor of more modular and modern backends.

Web-Based Doesn’t Mean Browser-Only

A common misconception is that web-based applications cannot run as desktop applications. In fact, technologies like Electron make it straightforward to package and deploy web-based tools as desktop apps, offering users a native-like experience. This flexibility allows you to choose the deployment model that best suits your users—desktop, browser, or both.

This Transition Also Involves Non-Technical Changes

A successful migration isn’t just about rewriting code. Your development team will need to onboard to a new technology stack, often adopting new programming languages, frameworks, and workflows. Deployment strategies may need to evolve—especially if you’re targeting cloud-based solutions, which introduce new considerations around infrastructure, DevOps processes, security, and cost models.

Your Users Will Experience a New Tool

From a user’s perspective, the migrated application is not simply an upgrade—it’s essentially a new tool. Even if the core functionality remains, the UI, interaction patterns, and workflows will change. This makes user onboarding, documentation updates, and change management critical to avoid frustration and resistance. Early demos, training sessions, and phased rollouts can help users adapt and see the benefits of the new environment.

Assess and Rationalize

Before you start developing, take time to thoroughly assess your current application’s strengths, weaknesses, and relevance in a web-based context. Ask critical questions: Are your workflows still aligned with how users want to work today, especially in distributed environments?

This is also the ideal stage to identify and remove unnecessary features or complexity. Many legacy Eclipse applications carry over years of accumulated functionality—often with large portions going unused. It isn’t uncommon that up to 80% of features in mature software are rarely or never utilized. Migrating these unused components without evaluation wastes resources and increases maintenance costs.

Equally important is to rethink workflows in the light of AI. Modern AI capabilities can simplify or even eliminate entire workflows by automating tasks, providing intelligent suggestions, and proactively surfacing insights.

Additionally, carefully assess the technology dependencies of your existing application—particularly the UI built on SWT/JFace. Many UI elements will need reimplementation using modern web technologies, making it essential to map dependencies clearly and early. Separating the core business logic from UI components allows for significant reuse during migration, making your project more efficient and cost-effective.

Plan for Reuse, Single Sourcing, and Backporting

Reuse of existing components can significantly lower the effort of a migration. In some cases, you can even achieve single sourcing, meaning the same component can be used in both the existing Eclipse-based solution and the new web-based tool in parallel. This pattern greatly reduces the effort for double maintenance during a migration phase.

Two proven patterns have worked particularly well in practice:

• Extracting business logic into headless components
  This approach works well for specialized features such as code generators, compilers, analyzers, or validation logic. If these features are not yet modularized, start by extracting them from the existing system into standalone components with a clear and interoperable interface—such as a CLI, REST service, or other standard APIs. Once separated, the same headless component can be integrated into the new web-based tool while continuing to be used in the existing Eclipse-based product for as long as needed.

• Backporting web-based features into Eclipse
  In this approach, you migrate a feature to web technologies but embed it into the existing application during the transition phase. For example, a part of the UI could be rewritten in HTML and displayed inside Eclipse using an embedded browser. This works especially well for frameworks like GLSP, where diagram editors can run in both environments. Similarly, migrating a DSL to the Language Server Protocol (LSP) allows the same language support to run inside both Eclipse desktop and the new web-based tool. These features can then be deployed in both versions simultaneously, ensuring consistency while reducing migration risk.

⚠ A Critical Perspective on Reuse
While maximizing reuse can reduce initial migration effort, it comes with potential trade-offs that must be considered carefully:

• Technology mixture - Carrying forward dependencies from legacy technologies (e.g., Java with OSGi) may require your team to maintain expertise across different stacks, slowing future development.

• Missed restructuring opportunities - Reuse may skip opportunities to simplify or modernize parts of the system.

• Architecture lock-in and technical debt - Existing constraints can influence the design of your new tool, potentially carrying forward legacy complexity.

Each component should be evaluated individually to balance short-term savings against long-term flexibility.

Next Steps: From Reuse Plan to Strategic Migration

Once you’ve defined your approach to reuse, single sourcing, or backporting, the natural next step is to consider how you will structure the migration project as a whole.

For detailed guidance on:

• Choosing your deployment strategy (desktop, browser, or cloud)
• Selecting the right foundation and technology stack
• Defining MVPs and Proofs of Concept
• Building the right team for the transition

…we recommend reading our comprehensive guide:

👉 How to Build a Custom IDE or Tool

That article provides a structured blueprint for these strategic decisions. In this migration-focused piece, we won’t repeat that content — instead, we’ll build on it by addressing migration-specific challenges that are often underestimated.

Managing the Dual-Tool Phase: Coexistence Without Chaos

For most organizations, migration is not a one-day “cut-over.” The old Eclipse-based tool and the new web-based tool will coexist for a period of time—and this is one of the most complex parts of the journey.

During this phase, you are effectively maintaining the legacy tool while building the new one from scratch. The challenge? This rarely works with the same budget and resources you had for just the old tool. Without careful planning, the migration can easily stretch on indefinitely.

There are also key strategic decisions to make:

• Feature allocation - Decide if new features go exclusively into the new tool, or whether some still need to be implemented in the legacy tool.
• Team dynamics - Clarify which teams work on which tool to avoid morale issues, such as parts of the team feeling like they’ve been left behind as the “legacy crew.”
• User adoption - Expect some resistance; not every user will be eager to switch.

One of the most important foundations is to have a clear, communicated migration plan. This plan should:

• Be explicit and reasoned, outlining the phases of migration, priorities, and timelines.
• Be communicated both internally (to align the development team and stakeholders) and externally (to keep users and partners informed).
• Be updated as needed—plans may evolve, but changes should be clearly explained to maintain trust.

There is no universal blueprint for solving all these issues, but the following principles help:

1. Move quickly, with adequate resources - Allocate enough budget and staff to ensure the new tool progresses at a sustainable pace.
2. Deliver benefits early - Roll out features or workflows in the new tool that create tangible improvements, drawing users toward adoption.
3. Be prepared for resistance - Some users will be reluctant to switch; accept that pleasing everyone is unrealistic during migration, but take their rationale as valuable feedback.
4. Support your team with clarity - Provide a clear perspective and roadmap so everyone understands their role and future beyond the migration.

Handled well, this phase becomes a managed transition instead of a stalled project. The key is to maintain momentum, keep communication open, and ensure both users and the development team see the long-term vision.

Moving from Strategy to Action

A successful migration is not just about understanding the right steps — it’s about putting them into practice at the right time, with the right architecture, and with the right skills on the team. Many of the most critical decisions happen early, precisely when teams have the least experience with the new ecosystem.

Having support from people who have navigated these transitions before can make all the difference — both strategically and in day-to-day implementation.

At EclipseSource, building tools and IDEs is our core business. We don’t just advise from the sidelines — we actively work with our customers on design, architecture, and hands-on development. Implementation services are a key part of what we do, and our team regularly joins projects for the full development phase.

We support migrations in three complementary ways:

• Consulting - Guiding strategic decisions, such as architecture, reuse planning, AI integration or deployment strategy — basically all of the topics covered in this article.

• Training - Transferring expertise to your teams, from web technologies to modern tool architectures, ensuring long-term independence.

• Implementation - Providing highly skilled developers who integrate seamlessly with your team, boosting capacity and helping deliver results faster, and also foster knowledge transfer.

Because migration phases often put pressure on both strategy and execution, we combine all three approaches to keep projects moving forward without losing sight of the bigger picture.

If you’re preparing for a migration — or are already in the middle of one — our experience can help you move forward with confidence. You can explore our migration services and custom tool development offerings to see how we can support your next steps.

👉 Contact us today to start your migration journey with confidence!

👉 Explore our Tool Development Services, Web and Cloud-Based Solutions, AI-Powered Tooling, and Eclipse RCP Expertise.

💼 Follow us: EclipseSource on LinkedIn

🎥 Subscribe to our YouTube channel: EclipseSource on YouTube