TypeScript in a SAPUI5 codebase

Context

An internal SAPUI5 application used daily by a logistics team. Around forty controllers, six years of history, and three people maintaining it. Every screen had been written in plain JavaScript against the UI5 module system.

Problem

The failures that reached production were almost never logic errors. They were shape errors: a field renamed on the OData service, a model path that no longer resolved, a controller reading a property the entity set had stopped returning. None of it was visible until someone opened the screen.

Approach

Migration ran one folder at a time, with feature work continuing in parallel. Type definitions were generated from the service metadata rather than written by hand, so the OData contract stayed the single source of truth. Controllers were converted only when they were being touched for other reasons, which kept the diff of any one pull request reviewable.

The build stayed on the existing UI5 tooling. Introducing a second bundler would have meant maintaining two build paths for the length of the migration.

Result

Not measured against a baseline — no error tracking existed before the migration, so any before-and-after number would be invented. What is observable: renames on the service now fail the build instead of a screen, and the three shape errors found during conversion had all been live in production.

Lesson

Generating types from the service metadata mattered more than the migration itself. Hand-written interfaces would have drifted from the backend within a release, and a type that lies is worse than no type at all.