Adobe Forms
ABAP Developmentadvanced

Adobe Forms Part 10: Migrating Smart Forms to Adobe Forms

Key takeaway

Plan and execute a Smart Forms to Adobe Forms migration: inventory and prioritisation, reusing driver data logic, SFP migration wizard vs redesign, mapping windows/tables/texts to subforms, testing with PDF comparison, output control switch-over and S/4HANA output management considerations.

Explanation

📌 KEY POINTS
✅ Migration is mainly a layout redesign: data logic from the Smart Form driver (and form program lines) should be moved into a reusable data provider first.

✅ SFP offers a migration function (Utilities → Migrate Smart Form) that creates an interface and form skeleton — a starting point, not a finished form.

✅ Test by comparing old and new outputs side by side (PDFs) for many real documents, languages and edge cases.

⚠️ Don't migrate everything: retire unused forms, replace custom forms with standard S/4HANA forms where possible, and prioritise by volume and business criticality.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE

Parts 1–9 built Adobe forms from scratch. Most projects, however, start with existing Smart Forms.

━━━━━━━━━━━━━━━━━━━━
▶ 1. INVENTORY

  • List forms, output types, drivers, usage volume (NAST statistics), countries/languages, owners.
  • Classify: retire, replace with standard, migrate, keep temporarily.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SEPARATE DATA FROM LAYOUT

  • Move all SELECTs and logic from form program lines/initialization into the driver or a data-provider class.
  • Define DDIC structures for the new interface (often the same as the improved Smart Form interface).
  • First deliver this refactoring on the Smart Form (no visible change) — then build the Adobe layout on the same data.

━━━━━━━━━━━━━━━━━━━━
▶ 3. BUILD THE ADOBE FORM

  • Option A: SFP migration of the Smart Form (creates interface/form) and clean up.
  • Option B: new design in SFP following corporate templates/design system (often better).
  • Mapping: main window → flowed body subform; secondary windows → master page elements or positioned subforms; table nodes → tables with DATA[*]; text modules → context text nodes.

━━━━━━━━━━━━━━━━━━━━
▶ 4. OUTPUT CONTROL SWITCH

  • NACE processing routine: new driver/ENTRY and PDF form (form type PDF).
  • S/4HANA output management (BRF+): form templates determined in the output parameter determination.
  • Switch per output type and country in waves.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TESTING

  • Generate PDFs from old and new forms for the same documents (100+ samples, edge cases: long tables, discounts, zero values, languages).
  • Compare visually and by extracted text where possible.
  • Print tests on real printers (device types, barcodes).

━━━━━━━━━━━━━━━━━━━━
▶ 6. CUTOVER

Transport interface, form, driver, text modules, graphics; ADS ready in all systems; reprint strategy for documents created before the switch.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Inventory your Smart Forms with output types and volumes.
  2. Refactor one Smart Form driver to a data-provider class.
  3. Build the Adobe form on the same class and compare 20 PDFs.

✅ CHECKPOINT: you can plan and execute a controlled Smart Forms to Adobe Forms migration.

Code example

ABAP Code
* ===== Shared data provider used by both Smart Form and Adobe Form drivers =====CLASS zcl_invoice_print_data DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    METHODS get_data      IMPORTING iv_vbeln  TYPE vbeln_vf      EXPORTING es_header TYPE zaf_inv_header                et_items  TYPE ztt_inv_items.ENDCLASS. CLASS zcl_invoice_print_data IMPLEMENTATION.  METHOD get_data.    DATA ls_vbrk TYPE vbrk.    CLEAR: es_header, et_items.    SELECT SINGLE * FROM vbrk INTO ls_vbrk WHERE vbeln = iv_vbeln.    CHECK sy-subrc = 0.    es_header-vbeln = ls_vbrk-vbeln.    es_header-fkdat = ls_vbrk-fkdat.    es_header-waerk = ls_vbrk-waerk.    SELECT posnr arktx fkimg vrkme netwr FROM vbrp      INTO CORRESPONDING FIELDS OF TABLE et_items      WHERE vbeln = iv_vbeln.  ENDMETHOD.ENDCLASS. * ===== Smart Form driver (before) and Adobe driver (after) call the same class =====* DATA lo_data TYPE REF TO zcl_invoice_print_data.* CREATE OBJECT lo_data.* lo_data->get_data( EXPORTING iv_vbeln = lv_vbeln*                    IMPORTING es_header = ls_header et_items = lt_items ).* Smart Form: CALL FUNCTION lv_sf_fm  ... is_header = ls_header it_items = lt_items* Adobe Form: CALL FUNCTION lv_af_fm  ... /1bcdwb/docparams = ls_docpar is_header = ... * ===== Migration checklist =====* Inventory -> classify (retire/standard/migrate) -> refactor data provider* -> build Adobe layout -> PDF comparison (100+ docs) -> printer tests* -> switch output routine per output type/country -> monitor

Real project scenario

A global company had 140 Smart Forms before its S/4HANA move. The inventory showed 45 unused forms and 30 replaceable by standard S/4HANA forms. For the remaining 65, the team first refactored drivers into data-provider classes, then built Adobe forms on a corporate template.
PDF comparisons with 200 documents per form caught rounding and language issues before go-live. Output types were switched country by country, and printing incidents after cutover were minimal.

Common mistakes

  • Migrating unused forms.
  • Carrying SELECTs from program lines into Adobe scripts.
  • Relying fully on the migration wizard.
  • Testing with a handful of documents only.
  • Forgetting ADS readiness in all systems.

Best practices

  • Inventory and retire first.
  • Shared data provider for old and new forms.
  • Redesign on corporate templates.
  • Large-sample PDF comparison and printer tests.
  • Switch output in controlled waves.

Interview angle

Questions: "How would you migrate Smart Forms to Adobe Forms?", "What can be reused?", "How do you test the migration?"
Strong answer: inventory with volumes, retire/replace with standard, refactor data logic into a data provider reused by both drivers, SFP migration or redesign mapping windows/tables/texts, switch NACE/output management per output type in waves, PDF comparison on many real documents and printer tests, ADS readiness.

Practice this lesson

Quick check

1. What is the recommended first step of a Smart Forms to Adobe Forms migration?

2. What can typically be reused when migrating a Smart Form to an Adobe Form?

3. Why is SmartForms to Adobe Forms migration not always a simple one-click conversion?

Interview questions

1. A company planned a one-to-one conversion of fifty Smart Forms to Adobe Forms. What would you recommend?

Answer it in your own words first, then compare.

2. How would you plan a SmartForms to Adobe Forms migration?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics