SAP PRA on S/4HANA: Brownfield, Greenfield, and the SR Soft Migration Cell

ECC PRA is a known beast. S/4HANA Oil & Gas PRA is a different animal: simplified data model, Business Partner, Universal Journal, Fiori, and a clock that does not care about your Z-allocation exit. Fortune 500 energy companies are in that tunnel. The ones who treat it as a technical upgrade discover in dress rehearsal that royalty formulas, DOI history, and plant statements do not “convert.”

Three patterns exist. Greenfield: new PRA, selected history, new interfaces. Brownfield: convert the beast, cleanse what you can, live with what you cannot. Selective data transition: take the objects that still have a legal life and leave the rest in an archive you can still PPA from. SR Soft staffs all three. We will not let a SI pick one in a slide without a data-object inventory.

What actually has to move

• Well, completion, measurement point, delivery network — and DOI history, not just current
• Allocation results you may need to reopen for PPA
• Royalty and tax formulas legal will not “simplify” for S/4
• Open owner payables and in-flight settlements
• SCADA, midstream statement, and checkstub interfaces
• Custom ABAP that RAP or CAP must replace, not hide in a compatibility pack forever

The exits that will not travel

A generation of PRA programs hid allocation and valuation in user-exits because the standard object was “not flexible.” On S/4 those exits are debt. We inventory every enhancement, tag it keep / replace / kill, and staff RAP or CAP for the replace list before functional freeze. If the SI says “we’ll handle exits in hypercare,” they are scheduling your second go-live.

Why the SR Soft cell is the architecture

We fill PRA, FICO (RTR), Basis/Security, and BTP in one vendor motion. We do not send a general SD consultant to “help with oil and gas.” We send people who have closed a production month on ECC and at least one who has stood up Fiori measurement. That mix is how we changed the face of these migrations: the staffing plan is the cutover plan.

2026–2028

Fiori inquiry for owners, Datasphere models for allocation explainability, Joule on settlement exceptions, Integration Suite for ticket ingest. None of that works if DOI lineage is a flat file. SR Soft is hiring and placing the mix that can do both the old month and the new metal. See Careers.

Data objects that decide the pattern

Greenfield, brownfield, or selective data transition is not a taste. It is a function of which DOI histories still have a legal life, which PPAs are still open, which custom exits encode royalty law, and whether Business Partner conversion will destroy owner numbers land uses in court. We inventory those objects before anyone says “brownfield is cheaper.” Brownfield with dirty DOI is not cheaper. It is a second go-live you did not schedule.

Compatibility packs and unused exits are not a strategy. Every allocation and valuation enhancement is tagged keep, replace (RAP or CAP), or kill. Replace work is staffed before functional freeze. If the SI parks exits in hypercare, they are scheduling your second cutover. We write that sentence into the SOW.

Dual-run is not a slide. It is one production month where ECC and S/4 both allocate, both value, both settle, and land signs both listings. Control totals, not a demo. Interface cut has a fallback window. Hypercare is a designed PPA factory: the first ninety days assume restatements. If your hypercare plan is “tickets,” you have not migrated PRA. You have installed it.

Fiori measurement, owner inquiry, and Joule on exceptions are the payoff — after lineage exists. Datasphere models that explain a missing Mcf are a BDC story. We staff that lane when the journal is honest. Not before.