SAP Data Loads After Go-Live

Every SAP migration guide ends at go-live, and the data loading does not. In the week after cutover, the migrated data is checked against reality and some of it is wrong. In the month after, the master data that was frozen for cutover unfreezes and a backlog of creates and changes lands. And from then on, every month end, every price change, every reorganisation, every acquisition brings a spreadsheet that has to get into SAP, and the migration project that knew how to do that has been closed.

This guide is about that period and what comes after it: the three kinds of load that follow a go-live, why the migration tooling is the wrong tool for two of them, who ends up doing the work, and how to run it with the same control the cutover had. It applies whether the go-live was a new S/4HANA system, a conversion from ECC, or a rollout of a new company code.

The three kinds of load after go-live

Delta loads

The last full data extract from the legacy system was taken days or weeks before cutover, to give the mock load time to run and reconcile. Everything created or changed in the legacy system after that extract is the delta, and it has to be loaded into the new system at cutover, after the main load and before the business starts transacting. New vendors onboarded in the last fortnight, materials created for a new product, price changes, address changes, the open items that were posted between the extract and the freeze.

Deltas are small in volume and large in risk, because they are loaded under time pressure, at the end of a cutover weekend, by a tired team, and because a delta that is missed is not discovered until the first transaction that needs it fails. The two controls that matter: a freeze on legacy master data changes as early as the business will accept, and a delta extract that is taken by object with the same query as the full extract, so the delta is a defined set rather than "whatever changed".

Corrections

The first weeks after go-live, usually called hypercare, are when migrated data meets real transactions. A material with the wrong valuation class produces a wrong posting on the first goods receipt. A vendor with the wrong payment terms gets paid at the wrong time. A cost center that was migrated with the wrong profit center throws every posting to it into the wrong segment. A customer whose sales area data was incomplete cannot be invoiced.

None of these were visible in the mock load reconciliation, because reconciliation checks that the data arrived as extracted, and these are cases where the extracted data was wrong or the mapping was. They are found by the business, one at a time, and the fix is usually not one record but every record with the same problem: 300 materials with that valuation class, every vendor from that legacy payment term, every cost center in that hierarchy node. Each is a mass change, in production, in the first month of a new system, by someone who needs it done today.

Recurring loads

From the first month end onward, the loads are operational. Journal entries prepared in Excel for accruals and allocations. A price update across a material range. New cost centers and profit centers for a reorganisation. A batch of vendors from an acquisition. Open items loaded for a new company code. Physical inventory counts. Customer credit limit updates. Exchange rates. The master data that follows every go-live, and the mass changes that never stop.

These are not migration. They are how the business runs, and the volume is why the migration existed in the first place. They land with finance, master data and operations users, in Excel, every month.

Why the migration tooling is the wrong tool for two of the three

The Migration Cockpit was built for the initial load into a new S/4HANA system. It does that well, and it is the right tool for the main load and for the delta loads at cutover, which are the same load again with a smaller file. It is run by the project team, it uses staging tables or a connected source system, and it is designed to be finished.

After cutover it is usually handed back. The project team rolls off, the staging system is decommissioned or repurposed, the migration objects were built for the legacy system's structures rather than for a spreadsheet a finance user fills in, and the person who wants to correct 300 valuation classes on a Tuesday afternoon has neither the tool nor the access nor the time to relearn it. The Migration Cockpit guide covers what it does; what it does not do is become the business's daily load tool, and it was not designed to.

LSMW is the tool ECC teams used for this, and it is where a lot of post go-live loads still happen on ECC. In S/4HANA it is restricted use, it receives no development, its recordings of customer and vendor transactions do not work, and it is absent from the public cloud. Objects built on the BAPI method still run, and where an S/4HANA on-premise team has them and knows them, they will keep using them for a while. It is not a plan.

What is left, in most companies, is three options: raise a development request for each load and wait, key the data by hand, or find a tool that lets the business load from Excel through SAP's standard interfaces with the controls the auditors saw at cutover. The rest of this guide is about the third.

Running loads after go-live with the same control as cutover

The cutover load had four properties that made it acceptable: every record was validated before it posted, the load ran through SAP's own interfaces, every record produced a result that was reconciled, and the run was logged. A load in month three needs the same four, and the controls are simpler than they sound.

Validate against the live system, every row, every time

The value of validation is highest after go-live, because the target is production and the loader is not a migration specialist. A row is checked against the live system before it posts: the cost center exists and is open on the posting date, the material type allows the valuation class, the vendor is not blocked, the period is open, the document balances. The SAP message appears beside the row, the row is fixed, and nothing has posted. This is the step that lets a finance user run a load that a consultant used to run.

Post through SAP's own interfaces, under the user's own login

Loads go through the same BAPIs the migration used: BAPI_MATERIAL_SAVEDATA, BAPI_ACC_DOCUMENT_POST, BAPI_COSTCENTER_CHANGEMULTIPLE, BAPI_PO_CREATE1 and the rest. That means every business rule the transaction applies is applied, change documents are written, and the created-by field on every record is a named person with the authorisation they already have. No technical user, no table writes, no recording that breaks when a screen changes. The same authorisation concept that governs the user in FB50 governs the user's load.

Keep the before values on every change

A correction in hypercare is a change to migrated data, and the migrated value is the audit baseline. Every mass change after go-live starts from an extract of current values, with the new value beside it, and the sheet with old value, new value and SAP result is kept. That is the reversal path and the evidence, and it is what the mass change procedure is built around.

Approve like a journal, log like a migration

A load of 300 corrections in production is a change that needs an approver, and most companies already have the mechanism: the same review a manual journal or a master data request gets. What changes is the evidence. The sheet with the result per row is the log, in the format the auditors saw for the cutover, and it answers "was this record migrated or corrected, by whom, when" for the life of the system.

A worked example: 300 materials with the wrong valuation class

Week two after go-live. The first goods receipts on a range of packaging materials post to the raw materials stock account, and the controller notices at the first weekly stock valuation. The cause is in the mapping: the legacy system had one material type for packaging and raw materials, the migration mapped it to ROH, and 300 materials that should carry the packaging valuation class carry the raw material one.

The fix is a mass change of the valuation class on 300 materials, in production, with stock already on some of them. Three things make it harder than it looks, and they are the reasons validation before the change matters here more than anywhere:

• SAP does not allow a valuation class change on a material with stock in the current or previous period. The materials that have received goods have to be handled differently from the ones that have not, and the load has to know which is which before it runs.
• The wrong postings already made have to be corrected separately, by reversing and reposting the goods receipts or by a manual adjustment, and that is a finance decision, not a master data one.
• The change is to migrated data, so the migrated value is the audit baseline and has to be kept.

In practice: the material master report is run from Excel for the 300 materials with the current valuation class and the stock per period, so the sheet shows which ones can be changed now and which need the stock cleared first. The new valuation class goes beside the old one. Validate runs every row against the live system, and the materials with stock come back with the SAP message before anything changes. The clean rows post through BAPI_MATERIAL_SAVEDATA under the master data lead's login, the result lands beside each row, and the sheet with old value, new value and result is filed as the hypercare change record. The remaining materials are changed after the stock is moved, from the same sheet.

None of this needed the project team, a development request, or the Migration Cockpit. It needed an extract, a validated load, and a person with the authorisation to run it.

Who runs the loads after go-live

The pattern in the table is that the owner changes from the project to the business between the first and second rows, and never changes back. A tool for loads after go-live is a tool the business runs.

Where PostNow.ai fits

PostNow.ai is built for the second and third kinds of load. It is an Excel add-in and a web portal. The user opens the sheet they already have, PostNow.ai maps it to the SAP object's BAPI (templates from the library are recognised by their headers), validates every row against the live SAP system with the SAP message beside each failing row, and posts through the BAPI under the user's own SAP login and authorisations. The document number or the message is written back beside every row, and the sheet is the log.

For corrections, the starting sheet is an extract of the current values, from the report library, with the new values beside them, so the before state is kept by default. For recurring loads, the mapping is saved with the template, and month two is fill, validate, post. Nothing is installed in SAP, nothing is recorded, nothing is transported, and it works the same on ECC and S/4HANA, which is what lets a finance team keep loading through a migration and out the other side without changing how they work.

Planning for it before go-live

Four things to decide before cutover, because after cutover nobody has time:

1. Which loads continue. List the recurring loads by object and owner. Most projects discover this list in month two. Make it in the design phase.
2. Who runs them. Name the business users, and give them the authorisations and the tool before the project team leaves, not after.
3. What the log looks like. Agree the per-row evidence format with internal audit during the project, while the cutover log is being agreed, so the operational loads inherit it.
4. What the hypercare correction process is. A correction of 300 records in week two is a change in production. Decide who approves it and how it is evidenced before week two.

Frequently asked questions