Migration cost modelling within the RISE TCO.

Migration cost is the line in the RISE with SAP TCO that is most often underestimated and least often defended. The headline RISE subscription cost is well documented in the proposal. The hyperscaler infrastructure cost is well documented in the bundle. The migration cost is left as a placeholder, with a number that came from the SAP partner's standard scoping template or from an internal estimate that has not been pressure tested. When the migration arrives, it costs two to three times the placeholder, and the TCO model that supported the original decision no longer matches the financial reality of the program. This article documents how to model migration cost within the RISE TCO so that the decision is made with eyes open.

Decompose migration into seven workstreams

Migration is not a single line. It is seven workstreams running in parallel, each with its own cost curve and risk profile. The seven workstreams are program management, technical architecture and design, data migration, custom code remediation, integration rebuild, testing and validation, and organisational change management. A migration cost line that does not decompose into these seven workstreams is hiding the variance.

The countermove is to model each workstream separately, with named effort estimates, named external rates, named internal allocations, and named duration. The aggregate is then the sum of seven defensible numbers, each of which can be challenged and refined. A model that produces a single migration cost number is, by definition, hiding most of what the audience needs to evaluate.

Distinguish brownfield from greenfield migration cost

Migration cost is materially different between a brownfield conversion to RISE and a greenfield rebuild on RISE. The brownfield conversion preserves custom code, integrations, and configurations, which reduces some workstreams but increases others. Custom code remediation is the dominant cost in a brownfield conversion. Integration rebuild is the dominant cost in a greenfield approach. The two costs are not equivalent.

The countermove is to model the chosen migration approach with the cost structure of that approach, not with a generic migration template. A brownfield conversion needs a custom code remediation budget that reflects the actual complexity of the buyer's code base. A greenfield approach needs an integration rebuild budget that reflects the actual breadth of the buyer's integration estate. Either model can be defended. A model that splits the difference defends neither.

Model the data migration carefully

Data migration is the workstream that most consistently overruns its budget. The reason is that data quality is unknown until the migration is in flight, and data quality problems consume effort and time that the original budget did not anticipate. The model should not assume that data quality will be discovered during migration and absorbed by the existing budget. The model should include an explicit data quality remediation reserve, sized to the data estate.

The countermove is to require a data quality assessment before the TCO model is finalised. The assessment identifies the categories of data that will require remediation, the volume of records in each category, and a defensible per record remediation cost. The result is a data quality line in the TCO that is grounded in the data estate, not in an industry benchmark.

Quantify the custom code estate

Custom code remediation is the cost line that most often surfaces only after contract signature, when the migration team begins the detailed assessment and finds that the custom code estate is larger or more complex than the executive committee was told. The countermove is to quantify the custom code estate before the TCO model is approved, with a tool based code scan that identifies object count, modification depth, and dependency complexity.

The code scan produces a defensible custom code line that the TCO model can stand behind. The line will not be perfectly accurate, but it will be grounded in the actual code estate rather than in a percentage of revenue heuristic. When the migration arrives and the cost matches the line within ten or fifteen percent, the model has done its job. When the cost matches a heuristic within forty percent, the model has lost its credibility.

Reserve for the surprises

Every migration produces surprises. The integration that was assumed to be straightforward turns out to depend on an undocumented middleware component. The data extract that was assumed to be a one time job turns out to require a sustained data engineering effort. The user training that was assumed to fit a standard curriculum turns out to require role specific design across thirty user types. None of these surprises are predictable individually. All of them are predictable in aggregate.

The countermove is to include a migration contingency reserve in the TCO model. The reserve is typically fifteen to twenty percent of the total migration cost, depending on the complexity of the source estate and the maturity of the migration team. The reserve is not a buffer for poor planning. It is a quantified provision for the surprises that every migration produces and that no plan eliminates.

Account for the parallel run

The most overlooked migration cost is the parallel run. For a defined period before cutover, the legacy estate and the RISE environment run in parallel, with effort going into both. The legacy estate continues to require operational support, license maintenance, and infrastructure cost. The RISE environment is consuming subscription cost during the build phase, before any business value has been captured. The parallel run period is typically nine to eighteen months for an enterprise scale migration.

The countermove is to model the parallel run as a separate line in the TCO. The model captures legacy operational cost continuing during parallel run, RISE subscription cost beginning at contract signature, and the team effort split across both environments. The parallel run line is often the largest single migration cost component, and it is the line most often missing from the original model.

Conclusion

Migration cost modelling inside the RISE TCO is the discipline that separates a model the executive committee will defend from a model the executive committee will distance from. The model that decomposes migration into seven workstreams, distinguishes brownfield from greenfield, prices data migration against actual data quality, quantifies custom code, reserves for surprises, and accounts for the parallel run is a model that will match operational reality within a margin the audience can live with. A model that treats migration as a single line will be wrong by a factor that destroys the executive committee's confidence in the team that built the model. The investment in migration cost detail is the investment that protects the credibility of the entire TCO.