Why S/4HANA implementations overrun
Most overruns trace back to a handful of decisions made, or avoided, in the first months of the project.
Rebuilding the old system in a new one. Workshops ask users what they do today instead of showing them the standard process, so the blueprint fills up with custom requirements that S/4HANA already handles differently.
The wrong edition for the business. Public edition chosen for a business that needs deep modification, or private edition chosen for a business that would run happily on standard. Either way the cost shows up later.
Data migration left to the end. Master data cleansing starts after build, mock loads fail on duplicates and missing fields, and cutover dates slip because customers, materials and open items are not ready.
Testing that cannot keep up. Integration and user acceptance testing are run by hand from spreadsheets, so each defect fix triggers another manual cycle and the plan compresses into the final weeks.
Integrations discovered late. Banks, EDI partners, the warehouse system and the tax engine all need interfaces, and some are only found when a key user asks where a file used to come from.
Go live, then nobody to call. The implementation team leaves after go live, support inherits a system it did not build, and month end close becomes the real test.