Move off Smart Forms and SAPscript without changing what your customers see

The output layer nobody budgets for

Forms are the part of an S/4HANA programme that gets discovered late. The functional scope is mapped, the code is assessed, the data migration is planned, and then someone asks what happens to the four hundred output forms, and the answer is that nobody has looked.

Smart Forms and SAPscript are legacy output technology. They still run, but they are not where SAP is going, and a transformation programme that leaves them untouched has deferred the problem rather than solved it. Meanwhile every one of those forms produces a document that a customer, a supplier, a regulator or an auditor reads.

Why forms are harder than they look

A form is not just a layout. It is a layout, plus the logic that decides what appears on it, plus the conditions that determine which variant a given transaction gets, plus years of accumulated special cases: this customer needs their PO number in the header, this jurisdiction needs a specific tax breakdown, this document type prints differently above a certain value.

That accumulated logic is the reason form migrations overrun. The layout converts in an afternoon. Working out why the layout does something odd on the third page of a multi-item delivery note takes a week, and there are four hundred forms.

What the agents do

Agents read the existing form definitions and the driver programs behind them, extract the layout structure and the output logic separately, and rebuild both on Adobe Forms. Separating layout from logic matters, because it is what turns a set of opaque legacy objects into something a person can read, review and later change without archaeology.

The conversion also surfaces what is actually in use. Form estates accumulate variants that no configuration path can reach any more, such as output types retired years ago and document types the business stopped using. Those get flagged rather than migrated, which reduces the estate before the work starts.

Validation is the deliverable

The conversion is not finished when the form renders. It is finished when the rendered output matches the original for real documents, and that comparison is where our specialists spend their time.

We generate documents from both the legacy and the converted form across a representative spread of real scenarios: different document types, different value bands, multi-page cases, the jurisdictional variants, the edge cases that only appear on certain item categories. Then we compare them. Any difference is either explained or fixed before sign-off.

This matters more than it sounds. A form that is 98% right is a form that produces a wrong invoice for some customers, and you find out from the customer.

Where this sits in a programme

Form migration can run in parallel with code remediation rather than after it, because the dependencies are narrow. Forms depend on data and on their driver programs, not on the wider remediation effort. Running them in parallel takes a serial chunk out of the critical path, which on a 2027 timeline is worth having.