· via dev.to (home feed)
SAP ships ABAP tools for VS Code, ending a decade of Eclipse-only development
SAP's ABAP Development Tools for VS Code are now generally available, ending years of Eclipse exclusivity with a language-server core and native MCP support — though classical ABAP coverage still lags Eclipse ADT.

SAP's ABAP Development Tools for Visual Studio Code have reached general availability in 2026, ending more than a decade in which Eclipse was effectively the only modern IDE for ABAP work. According to an analysis published on dev.to, the release matters less as a matter of editor preference and more as a strategic shift: the tooling sits on open protocols that make ABAP reachable from the wider, and increasingly AI-driven, developer ecosystem.
What actually shipped
The dev.to piece points to several architectural choices that separate the new tooling from Eclipse ADT. Language services are delivered through the Language Server Protocol rather than Eclipse's closed plug-in architecture, which makes the stack easier to extend and to wire into outside processes. The extension was also designed around the Model Context Protocol from the outset, so AI tooling connects natively instead of being bolted on after the fact. Developers additionally gain access to VS Code's extension marketplace — the article names GitHub Copilot, Prettier and ESLint as examples — and the editor reportedly carries a smaller memory footprint and faster startup than Eclipse, which the author flags as significant for containerized development environments.
Strong for RAP, thin for classical ABAP
Coverage in the first release is deliberately uneven. Support is strongest for the RESTful Application Programming model and Fiori-oriented artifacts: business services, service definitions and bindings, projection views, metadata extensions and consumption models are described as well covered. Classical ABAP objects fare worse. Classes and interfaces support basic navigation and definition work but limited refactoring; function modules were view-only in early releases, with editing arriving gradually; reports get syntax highlighting and little beyond it. Classical dynpros, module pools, SAPscript and Smart Forms are view-only or unsupported, and there is no visual screen painter.
The author reports that SAP has committed to 80% object-type parity with Eclipse ADT by the end of 2026 and full parity by mid-2027, while cautioning that some GUI-based tools, such as the Screen Painter, may never receive a VS Code equivalent.
Built for an agentic workflow
The MCP foundation is the most distinctive part of the release. According to the dev.to analysis, developers can invoke ABAP MCP server tools directly from the editor to inspect tables, call RFCs and run syntax checks without leaving their code. External agents — Claude, GitHub Copilot and Amazon Q are named — can connect over MCP and draw context from open files and selections. Proposed changes appear as inline suggestions with git-style diff views for accepting or rejecting them. ABAP Unit tests run in-panel with click-through navigation to failing assertions, and transport requests can be created and managed without switching to SE09 or SE10.
Eclipse is not retired yet
For all of that, the analysis is explicit that many scenarios still require Eclipse: the screen and menu painters, SAPscript and Smart Forms maintenance, batch input and LSMW tooling, visual Web Dynpro development, deep SAT performance analysis, full transport organizer functionality, workflow builders and IDoc administration. The recommended posture is coexistence rather than replacement — running both IDEs against the same backend and letting developers choose per task. Teams maintaining pre-S/4HANA code in particular may find Eclipse more productive for now.
On rollout, the article covers the expected operational ground: single sign-on via Kerberos or SAML, shared connection profiles for multiple systems, secure credential storage, ABAP Test Cockpit violations surfacing in real time in the editor, format-on-save and dead code checks, and a standardized .code-workspace file bundling recommended extensions and settings for the whole team.
Why it matters
ABAP has been one of the last major enterprise languages locked inside a proprietary IDE silo. Moving it onto LSP and MCP makes ABAP a target for the same editors, extensions and coding agents the rest of the industry already uses, and gives SAP a credible answer to developers who avoided the platform because of its tooling. The gap between announcement and full capability is real, however: teams adopting now should plan around RAP-centric strengths, a two-IDE reality that will persist well past the mid-2027 parity target, and a sober audit of which legacy object types they actually touch day to day.
- #sap
- #abap
- #vs-code
- #mcp
- #developer-tools