Data migration strategy for RISE conversion.

Every RISE conversion conversation eventually arrives at the same uncomfortable question. What happens to twenty years of master data, transactional history, custom tables, and integration footprints when the system moves to the RISE tenancy. The SAP account team tends to treat data migration as an implementation detail. It is not. Migration scope, parallel run requirements, cutover commitments, and post conversion data accessibility are commercial levers that shape the seven year cost of the program. This article documents the buyer side discipline that turns migration from a hidden risk into a managed one.

Decide migration scope before the order form is signed

The first decision in any RISE data migration is scope. Not every record in the existing system needs to land in the RISE tenant. Buyers who treat migration as a lift and shift exercise import everything, then discover that the RISE FUE counts, the storage charges, and the BTP integration costs are higher than the proposal modelled. Buyers who decide scope before signing the order form get to negotiate around the number that matters.

Three categories of data deserve explicit treatment in the scope decision. Live transactional data within the relevant audit horizon, typically two to seven years depending on jurisdiction. Open documents at cutover, including in flight purchase orders, sales orders, deliveries, and invoices. Master data records that drive day one operations. Everything outside those three categories belongs in an archive conversation, not a migration conversation.

The discipline of writing the scope decision into the order form schedules protects the buyer from scope creep during cutover. SAP and the system integrator both have commercial reasons to expand scope during the program. A scope statement that pre commits the volume of records, the number of historical periods, and the integration endpoints in scope is the contractual anchor that holds the program to the original economics.

Build the archive strategy first, the migration strategy second

The archive strategy determines the migration strategy. Buyers who treat them as separate workstreams end up paying twice. A documented archive plan for non migrated data, with a retention rule per record type, a retrieval path for audit and legal hold, and a defined retirement date for the legacy system, is the foundation that lets the migration scope shrink to what is actually needed in RISE.

Common buyer mistakes include keeping the legacy ECC running indefinitely as a read only archive, which carries license and infrastructure cost. Importing twenty years of finance data into RISE storage to satisfy a tax retention rule that could be met with a flat file. Migrating obsolete master data because the team that owns it cannot decide what to retire. Each of these decisions adds permanent cost to the RISE TCO that should have been removed by a deliberate archive plan.

The archive plan also matters contractually. RISE order forms do not always include a clean exit path for data hosted in the tenancy. If a buyer ever wants to leave RISE, the archive of pre RISE data still needs to be accessible, and the post RISE data needs a documented extraction path. The archive strategy and the exit strategy are the same conversation.

Cleanse before you move, not after

Migration is the most expensive moment in the seven year RISE program to clean master data. The migration team has the records open, the business owners are engaged in cutover preparation, and the cost of fixing a record before it crosses into RISE is a fraction of the cost of fixing it once it has been integrated, reported on, and consumed by downstream systems.

The discipline is to run a cleansing wave before the formal migration wave. Vendors with no transactions in five years. Materials with no movement and no open BOM linkage. Customers flagged as inactive. Cost centres no longer in the organisational structure. Each of these record families can be retired or merged before migration starts. The result is a smaller, cleaner data set landing in RISE, which reduces FUE allocation pressure, reduces report runtime, and reduces the surface area for post go live errors.

Buyers who skip the cleansing wave inherit every issue that exists in the legacy system, then pay system integrator day rates to fix them after go live. The economic case for cleansing before migration is consistent and large. Across more than five hundred engagements, cleansing before migration has reduced post go live data remediation cost by between forty and seventy percent.

Architect the parallel run for confidence, not for theatre

Parallel run is the most common location for cost overruns in a RISE conversion. The temptation is to run a long parallel period for psychological safety. Three months becomes six, six becomes nine, and the cost of running two systems in parallel exceeds the original migration budget. The buyer side discipline is to design the parallel run for confidence, with measurable exit criteria, then commit to it.

A well architected parallel run has four components. A defined scope of business processes covered in parallel, not every transaction in both systems. A reconciliation methodology, with daily or weekly checkpoints and tolerance bands for matching. A defined exit criteria, with a documented decision authority that closes the parallel period when the criteria are met. A cost ceiling, agreed with the system integrator, that prevents the parallel run from becoming an open ended engagement.

The contract conversation around parallel run belongs in the system integrator agreement, not in the RISE order form. The order form should reference the cutover date, the support model during cutover, and the SAP responsibilities for the production tenant. The system integrator agreement should commit to the parallel scope, the duration, the cost, and the exit criteria.

Cutover discipline is contractual, not heroic

Cutover weekends are where good migration programs go wrong. The fatigue at cutover, the volume of decisions taken under time pressure, and the dependency on multiple parties to act in sequence creates conditions in which mistakes compound. The buyer side discipline is to make cutover a contractual event with named owners, defined deliverables, and documented decision rights, not a heroic effort that depends on individual diligence.

Specific cutover commitments to write into agreements include the timing and content of each freeze on the legacy system, the schedule of data loads into RISE, the validation steps and sign off owners at each stage, the rollback decision authority and the rollback technical path, the go live communication and incident process, and the post go live hypercare scope and duration.

The cutover plan is also where SAP commitments matter in the RISE order form. The buyer should secure named technical contact availability during the cutover window, defined response times for production incidents in the first thirty days, and acceleration paths for SAP escalation in the event of platform issues. None of those commitments are standard in a RISE order form. All of them are negotiable when the buyer raises them.

Build the data accessibility commitment into the contract

Data accessibility after RISE go live is a commercial risk that few buyers price into the seven year TCO. The RISE tenancy holds the data, the buyer pays for storage and FUE, and the buyer assumes the data will always be accessible at the speed and cost the proposal modelled. In practice, large data sets, complex reporting requirements, and integration with external analytics platforms can produce accessibility issues that translate into BTP consumption charges, integration redesign, or shadow data warehouse builds.

The contract should commit to specific accessibility terms. Defined extract patterns for finance, supply chain, and HR data. Reasonable export volumes and frequencies without consumption based charges. Documented integration patterns for analytics platforms and downstream systems. A data egress commitment that survives termination, with defined export formats and time windows.

Buyers who write these terms into the order form treat data as an asset they continue to own under RISE. Buyers who do not write them in find that data accessibility becomes a series of small recurring negotiations across the seven year contract, each one with cost attached. The contract is the single best moment to set those terms, and the cost of doing so is approximately zero.

Conclusion

Data migration in a RISE conversion is a commercial decision dressed as a technical one. Scope, archive strategy, cleansing, parallel run, cutover, and post go live data accessibility are each a place where seven year cost moves by material amounts depending on the discipline applied. The buyers who treat migration as a contract conversation, not a project conversation, end with a RISE tenancy that contains the right data, accessed in the right way, at a cost the original proposal anticipated. The buyers who treat it as a technical detail discover the missing economics during hypercare, when the leverage to fix them has already evaporated.