Where every SAP development transaction code's job now lives — SE80/SE11/SE38/ADT to Visual Studio and Application Explorer, transports to Git and deployable packages, ST05/SE30/ST22 to Trace Parser and Environment Monitoring — and an honest account of where the SAP toolchain is still sharper.
Every SAP developer carries a mental map of transaction codes that is really a map of jobs to be done: SE80 to browse and edit, SE11 to define data, STMS to promote a change, ST05 when something is slow, ST22 when something breaks. None of those jobs disappear on D365 F&O.
SE80's promise was a single Object Navigator: one tree, branching into packages, programs, classes, function groups and Dictionary objects, all reachable and editable from the same place. D365 keeps the idea of a navigable metadata tree but splits the implementation in two.
The Application Object Tree organises everything you build around three ideas, and getting them right early avoids a category of confusion that otherwise persists for months.
SAP's ABAP Dictionary separates a domain (the technical type, length, decimals, and optionally a fixed set of allowed values) from a data element (the semantic wrapper around a domain that carries the field labels a user actually sees). Two objects, one relationship, no inheritance between data elements themselves.
A transport request in SAP is both a unit of change and a unit of promotion: a workbench or customizing request, broken into tasks, released as a whole and imported in sequence through STMS-defined transport routes from DEV to QAS to PRD.
D365's environment tiers echo the three-system landscape's intent — separate spaces for building, proving and running — while changing both the mechanics and the default cadence.
The ABAP Debugger's core ideas — set a breakpoint, step through, inspect variables — transfer directly to the Visual Studio debugger attached to an Application Object Server process. Session breakpoints and external (shared) breakpoints both have a Visual Studio analogue;
D365's best-practice checks run automatically as part of every build — no separate step to remember, unlike invoking the Code Inspector or ATC on demand — enforcing a large built-in rule set covering naming, layering, label usage and security references, extensible with custom rules through the same best-practice rule framework Microsoft…
The tools change names and, in a few places, change shape entirely, but the jobs they do are recognisable end to end.