Nobody tells you upfront that moving from classic ABAP to ABAP Cloud isn't really about learning new syntax. The syntax is the easy part, you pick up define behavior for and EML statements in a couple of weeks. What actually takes longer is unlearning a set of habits that were correct, even good practice, in the world you came from, and are now the exact things a reviewer flags on your first RAP behavior pool.
SELECT * stops being a power move
In classic ABAP, if you needed a field that wasn't in the structure you were working with, you went and got it. Direct table access, a join, a quick SELECT against whatever table actually had the data. That instinct doesn't transfer. ABAP Cloud restricts you to released APIs and CDS based entities, and a lot of standard tables you could reach with SE16N for years simply aren't released for cloud development at all. The first time you hit that wall, it feels like losing capability you used to have. What it's actually doing is forcing you to find the released CDS view or API that SAP intends for that data, which is the same data you were getting before, just through a door that won't get bricked the next time SAP restructures the underlying table. The power move used to be knowing every table by heart. Now it's knowing which released entity exposes the thing you need.
The append structure habit you have to retrain
Need a flag on a standard table. Classic answer: append structure, add the Z field, done in ten minutes. That instinct has to go. ABAP Cloud extensibility works through the supported extension framework, custom fields and custom logic apps, or genuinely separate custom entities wired in through proper associations. The first few times this feels like more ceremony for a problem that used to take ten minutes. It is more ceremony. It's also the difference between an extension that survives the next upgrade cycle untouched and one that breaks the moment SAP changes something near the field you appended onto a table you don't own.
FORM routines taught procedural thinking, RAP wants object lifecycle thinking
A career built on FORM, PERFORM, and global data across a program teaches you to think in a straight line: the program starts, does a sequence of things, and ends. RAP behavior implementations are built around an object's lifecycle, create, validate, determine, save, each with its own handler method and its own moment in the sequence the framework controls, not you. People with twenty years of FORM routine habits often write their first behavior pool as one enormous method trying to do everything in one place, the same way they'd have written a single PERFORM that handled the whole transaction. That's usually the first thing a senior reviewer catches, not because the logic is wrong, but because cramming validation, determination, and save logic into one undifferentiated block defeats the entire point of a framework that wants those phases kept separate so it can manage concurrency and partial saves correctly.
COMMIT WORK was always yours to call. Now it isn't
Classic ABAP lets you call COMMIT WORK pretty much whenever you decide something needs to be durable. It's second nature after enough years, you write the update, you commit, you move on. In RAP, the framework owns the save sequence end to end, early numbering, finalize, the actual save. Calling COMMIT WORK manually inside a behavior implementation doesn't usually throw an obvious error. It just quietly breaks the locking and rollback guarantees the framework was supposed to be giving you, in a way that only shows up under concurrent access, which means it can sit in production for months before two users hit the same draft at the same moment and something doesn't roll back the way it should have. This is the habit that's hardest to unlearn precisely because nothing punishes you for it immediately.
Testing stops being run it and look
A lot of classic ABAP testing, especially under AMS deadline pressure, is functionally running the transaction by hand and eyeballing whether the output looks right. RAP development pushes toward writing actual unit tests against the behavior implementation, using test doubles and EML statements to exercise create, validate, and determine logic without touching a real database, which is a genuinely different discipline than clicking through SE80 and checking a result on screen. It's slower to set up the first time. It's also the only way to catch a determination that silently stopped firing correctly after someone else's unrelated change three sprints later, instead of finding out from a user ticket.
What doesn't change
None of this makes deep classic ABAP knowledge dead weight. Every RAP or CAP app on a brownfield S/4 landscape eventually reads or writes data that classic ABAP put there, following business rules that classic ABAP enforced for fifteen years before anyone wrote a behavior definition against it. Knowing how the standard tables actually behave, where the BAPIs cut corners, what a particular movement type really does under the hood, that knowledge doesn't get replaced by RAP, it becomes the thing that lets you build a correct behavior implementation instead of a plausible looking one. The habits change. The depth underneath them is still the asset.