Keeping extensions upgrade-safe

The extension itself is upward compatible. Everything around it is not automatically so: the exit's interface can change, the data your class reads can move, a support package can change how the standard function module fills a neighboring segment, and the middleware mapping depends on all of it. Upgrade safety comes from three habits: documentation, ownership and a regression pack.

Document every extension

Contoso's interface catalog lists about 25 IDoc interfaces. When the team inventoried them before the conversion, it found 11 extensions carried over from ECC, four of them with no known owner and two filling segments no partner still read. The register exists so that the next inventory, before the move to SAP Integration Suite, takes an afternoon instead of three weeks.

A regression pack for extended IDocs

Regression tests for an extension compare IDoc content, not just status. The most effective technique is a golden IDoc: a known billing document whose IDoc content was checked and approved, kept with the test. After an upgrade or support package, the same billing document is output again in the test system and the new IDoc is compared segment by segment with the golden one, including the custom segment, before the 810 is checked end to end.

Upgrades and the clean core conversation

During an upgrade, the check list for each extension is short. Is the exit still called at the same point with the same parameters (SMOD documentation, a quick debugger run with WE19)? Do the CDS views and tables the class reads still exist and mean the same? Does ATC report new clean core findings for the class? Does the golden IDoc still match? If any answer is no, the fix goes into the class, not into the include.

Longer term, Contoso's clean core goal for integration is fewer, smaller extensions. When interfaces move to SAP Integration Suite after hypercare, each extension is reviewed again: can the partner's need now be met from a standard API or event, can middleware derive the value, or is the extension still the simplest stable option? An extension that passes that review stays, documented and tested. That is a perfectly good outcome; clean core is about knowing and controlling extensions, not about having none.

Who approves a new extension

Because every extension adds custom code to a business-critical interface, Contoso treats a new one like any other custom development. Theo records the extend-or-map decision with the partner's requirement, Kenji estimates the exit work and confirms which data sources the class will read, Priya adds the regression cases before development starts, and the request goes to the same design authority that approves other custom code under the clean core rules. Small as it is, ZCMCINV1 went through that path in two days; the point is not bureaucracy but making sure the next upgrade test knows the extension exists.