You're probably looking at a project plan that says the database move will fit into a weekend, while nobody can yet tell you which historical data is moving, who owns the customer duplicates, or which interfaces still depend on RFC. That's the normal starting point for SAP HANA data migration, and it's why go-lives slip even when the technical team is strong.
The database starting successfully isn't success. Success is finance closing, planning producing sensible numbers, and interfaces feeding the business on Monday morning. In the 2025 SAPinsider S/4HANA migration survey, 32% of respondents had transitioned to S/4HANA, 27% were actively implementing, and 21% were still evaluating. Many programs are therefore still making the scope, ownership, and cutover decisions this playbook works through.
Table of Contents
- The Five Migration Phases and Their Exit Gates
- Assessing the Landscape and Deciding What Data Moves
- How to Extract and Transform Without Long Downtime
- Mitigating RFC Deprecation in Your Extraction Path
- Choosing a Cutover Method and Rollback Window
- Validation and Business Testing Before Go-Live
- Run Hypercare and Book Your Readiness Review
The Five Migration Phases and Their Exit Gates
Use the sequence below as your control structure, not as decoration for a steering pack.
| Phase | Core work | Exit gate |
|---|---|---|
| Plan | Inventory versions, OS, database size, table count, interfaces, licensing, HA/DR | Scope and cutover constraints signed off |
| Preparation | Migration users, compatibility checks, recoverable backups, rollback criteria, non-production rehearsal | Rehearsal completed within agreed timings |
| Execution | Monitor throughput, failures, logs and migration events | All objects loaded with exceptions logged and explained |
| Validation | Reconcile metadata, record counts, object status, sampled values, application behavior | Signed reconciliation and business-owner acceptance |
| Finalization | Application restart and rebind testing, tested fallback, handover to operations | Tested restore or fallback and go-live sign-off |
Why the gates matter more than the dates
Plan, Preparation, Execution, Validation, and Finalization only work if each phase can block the next one. Planning inventories source and target versions, operating systems, database size, table count, interfaces, third-party dependencies, HA/DR design, licensing, and cutover constraints. Preparation then creates migration users, confirms compatibility, proves backups are recoverable, defines rollback criteria, and rehearses in non-production.
Execution isn't one batch job you leave running overnight. You monitor throughput, failures, logs, and migration events as separate signals, because a load can appear complete while individual objects sit in error. Validation reconciles metadata, record counts, object status, sampled column values, application behavior, and performance under representative load.
An exit gate without a named signer is a status update, not a gate.
For early sizing, SAP's HANA Cloud migration validation guidance documents up to 1 TB within 12 hours in a supported scenario, with actual throughput varying by size, table count, network, and infrastructure. Treat that as a preliminary benchmark only, then measure your own workload including validation and rollback time. Programs slip at gates when teams sign paperwork for incomplete inventories, untested interfaces, or record-count differences nobody has explained.
Finalization requires application restart and rebind testing plus a tested restore or fallback. Do a quick self-check now. Can you name the exit gate for every phase in your plan, and who signs it?
Assessing the Landscape and Deciding What Data Moves
At go-live, the database can start while business users still face missing records, duplicate customers, or reports they cannot trust. Decide what moves by testing whether the resulting data will support business continuity and reliable decisions, not merely whether HANA accepts the load.
Finish the inventory before choosing a method
Record source and target versions, total size and growth, table count, and the largest tables with their change rates. Include clustered and pooled tables, custom code, interfaces, third-party dependencies, and HA/DR design. Assign an owner to each inventory area and resolve gaps before approving the migration method. Missing dependencies tend to surface during rehearsals, when fixing them consumes time reserved for testing.
Give every dataset one of five decisions, with a business sign-off for each:
| Decision | Choose it when | Sign-off owner |
|---|---|---|
| Retain and migrate | Records are active or legally required for daily use | Domain data owner |
| Archive | Closed history is needed for reference, not daily processing | Finance or legal lead with the data owner |
| Enrich | Records lack attributes required by new processes or reports | Domain data owner |
| Deduplicate | Customers, suppliers, or materials appear more than once under different keys | Master data governance lead |
| Redesign | A process change makes the old structure obsolete | Process owner with the solution architect |
When a partial move suits the business better than carrying all history forward, a selective data transition approach can apply these decisions by company code, time slice, or business unit.
Data quality is an ownership problem
Cleansing tickets alone do not decide who resolves a conflicting supplier record, which rules apply to materials versus finance, or how much data needs transformation. Set those decisions with named owners, then give them time and budget to resolve exceptions. The 2026 SAP Data Management Report reports that 27% of respondents named business resource availability as a top migration challenge, while 22% named data quality. The report also says 90% of surveyed organizations recognized that migration requires data and process transformation, and 50% believed more than half their data and processes must change. Those figures make ownership and resourcing worth testing in the program plan, rather than assuming cleansing will fit into spare capacity.
Global operations need rules that account for local retention law, multiple currencies, plants, and company codes. A single cleansing policy may not fit every region, and master data ownership can vary by location. Record which rules apply to each domain and who can approve exceptions.
Set acceptance criteria before extraction starts:
- Completeness: Required fields and records are present for each domain.
- Uniqueness: Duplicates resolve to a surviving record approved by its owner.
- Referential integrity: Customer, material, and finance keys still join correctly.
- Reconciliation tolerance: Agreed variance limits are documented before cutover.
- Named sign-off: A business owner accepts the result for each domain.
Fund remediation and assign owners before rehearsal. If either is missing, the program has no accountable data quality plan, and unresolved issues can undermine business decisions after go-live.
How to Extract and Transform Without Long Downtime
At cutover, a large table can consume the window even when the network has spare capacity. The risk is usually workload: teams start moving data before they know which tables are largest, change fastest, or depend on objects loaded elsewhere. Classify the work first, then size the transfer.
The seven-step routine
- Classify tables by size and change rate. The largest, most volatile tables set the likely downtime window. Estimate transfer time and account for changes that accumulate during the move.
- Remove or archive obsolete data. Reduce volume before migration where retention rules and business owners allow it. Less data to move also means less to reconcile, provided the business has approved what can leave the system.
- Check clustered and pooled tables and dependent objects. Map dependencies and confirm the required load order. Skipping this check can leave missing objects, broken dependencies, or a load sequence that has never been tested.
- Split large tables into parallel units. Use parallel extraction or export to make better use of available capacity rather than relying on one serial stream. Document the split logic so each rehearsal and the live run use the same approach.
- Run repeated mock migrations. A single rehearsal confirms that the path works. Repeated runs reveal timing variation, operator errors under pressure, and unclear runbook steps.
- Measure throughput with production-like volumes. Small samples hide contention, indexing costs, and slow outlier objects. Test at realistic scale before estimating the downtime window.
- Give measured timings to the cutover decision-makers. The business can then accept or reject a measured window, with assumptions visible, instead of relying on an estimate no one trusts.
What a measured case shows
A published Oracle to HANA migration case reported a 10 TB source compressed to 3 TB. Table splitting and parallelization reduced downtime by 25%, and the migration finished in less than 36 hours. These are results from that case, not a forecast for another environment. The practical point is that measured baselines and parallel workstreams shaped the window.
The same source describes a survey of more than 200 large-company decision-makers. It reports that 18% implemented new processes and technologies during migration, 49% made few or no changes, and approximately 60% of SAP migrations fell behind schedule or budget. Underestimated complexity and scope expansion were identified as main causes. Keep the extraction scope stable across rehearsals, and assign business owners to approve any data or process changes. Otherwise, the timing results are based on a moving target, and they cannot support a reliable continuity decision.
Practical rule: Wide variation in mock-run timing means the cutover window is not yet predictable. Find the source of variation before setting the go-live gate.
Where tooling helps and where it doesn't
Native SAP tooling handles the core extraction and load. Accelerators can support the surrounding work. Velocity handles no-code SAP to Azure ingestion, while Pulse supports planning, execution, and validation for migration programs. These tools may shorten measurement and rehearsal cycles when the same extraction must run repeatedly.
Neither tool replaces a mock run. A fast demo does not establish that your largest table will move within the change freeze, under your network conditions. Test the tooling with production-like volumes during measurement and rehearsals, and retain the results. Use those timings to set the cutover go/no-go criteria. A migration is ready when the business can maintain continuity and trust its decisions on the target system, not merely when HANA starts.
Mitigating RFC Deprecation in Your Extraction Path
RFC risk is quiet. A connection that has worked for years doesn't always fail loudly after cutover. Sometimes an external system just stops receiving data, and the business finds out from a missing report or a stalled feed.
Start with a complete list of every RFC-enabled function module, custom ABAP extraction program, scheduled job, and third-party connector. Classify each one as retire, replace, or keep behind a gateway. Check current SAP documentation and notes for your target release as you triage, because deprecation timelines change and shouldn't be fixed from memory or from an old project slide.
| Pattern | Exposure | Mitigation |
|---|---|---|
| Custom RFC function modules called by external systems | High, fails silently after cutover | Inventory every caller, replace with a supported service, run a parallel period |
| Third-party tools connecting over RFC | Medium to high | Confirm vendor support on the target release and test under production-like load |
| Scheduled batch extraction built on RFC | High for batch windows | Rebuild the job and time it in the mock run |
| Reports reading tables directly | Low to medium | Rewrite against CDS-based or other supported views where available |
Triage by business volume, not by age
Replacement options include SAP-supported APIs and extraction services, ODP-based extraction, OData, CDS-based services, and connectors your vendor supports on the target release. Prototype throughput for each replacement against mock-run volume, not a small sample. Then run side-by-side extraction with row-count comparison before you switch any feed over.
For a structured view of what compliant extraction looks like as legacy routes close, review this guide to SAP-compliant data extraction before and after ODP and RFC restrictions alongside your own inventory.
The video below walks through the extraction problem in practical terms.
Keep compliance visible while you rebuild. Log who accesses which data, and scope technical users narrowly to the objects each feed needs. Broad technical users created during migration have a habit of surviving into production.
Don't rebuild everything to the same standard. A legacy job that runs once a quarter may only need a documented bridge with a named owner and a retirement date. Spend the rebuild effort on feeds carrying daily business volume, where a silent failure stops orders, postings, or reporting.
Choosing a Cutover Method and Rollback Window
Pick the cutover method from measured timings and recovery objectives, not from team habit. The table below compares the four routes most SAP HANA data migration programs consider.
| Method | Downtime profile | Rollback path | Best fit |
|---|---|---|---|
| Backup and restore | Scales with database size and restore time | Restore the pre-cutover backup, which takes time | Smaller databases with a tolerant window |
| System replication | Short cutover once replication lag is closed | Fallback to source possible while replication is configured | Tight recovery objectives on a supported topology |
| Export and import | Tied to load throughput and validation effort | Needs a reverse plan or a retained source | Restructuring during migration or heterogeneous sources |
| Upgrade-integrated | Bound to the duration of the conversion run | Source retained as the fallback | Combining the database move with an ERP conversion |
How to read the comparison
Backup and restore is simple to explain and slow to reverse. System replication buys a short cutover, but only where the topology is supported and replication lag is fully closed before you commit. Export and import gives you room to restructure, yet it ties your window to load and validation effort, and it needs a reverse plan you have carefully thought through. An upgrade-integrated route combines moves, which reduces separate events but concentrates risk into one long run.
For export and import, use the preliminary throughput figure from the earlier section only as a starting point. Your mock-run measurements override it, because real throughput depends on database size, table count, network traffic, and infrastructure.
Model rollback before you need it
Define your recovery point objective and recovery time objective in business terms. How much data can the business afford to re-enter, and how long can it wait? Decide how long the source stays frozen or synced, estimate what a reverse data flow costs in time, and name the person who calls rollback at the go and no-go gate.
Track these metrics at that gate:
- Mock-run variance: Measured rehearsal time against the planned window.
- Open validation exceptions: Count and severity, not just a total.
- Reconciliation closure time: How long sign-off took in rehearsal.
- Rollback readiness: Tested, timed, and staffed, not assumed.
If the business can't accept the downtime from your last mock run, change the method or the scope. Don't just move the date.
Changing the schedule alone rarely fixes a window that was never measured. A method is viable when the measured window fits the business constraint and rollback fits inside the same change period. Anything else is a negotiation you're postponing to cutover night.
Validation and Business Testing Before Go-Live
The most damaging migration defect loads cleanly. Record counts match, the database performs, and then planning, inventory, credit, tax, or management reporting produces the wrong answer without any warning. Technical reconciliation won't catch that, because the data is valid. It's just wrong for the business decision it feeds.
The Kyndryl SAP transformation research drawing on the 2025 SAPinsider benchmark found 84% of respondents considered a smooth transition important or very important, while 43% said their current SAP environments were too complex to migrate. That combination explains why testing has to be organized around business risk rather than load success.
| Check | How to run it | Pass criterion |
|---|---|---|
| Record counts | Compare counts per table between source and target, including extra and missing rows | No unexplained variance |
| Object status | Confirm no error-state objects and no unexpected datatype changes | Zero open errors |
| Sampled column values | Field-level comparison on key fields and high-value samples | Every exception explained and signed |
| Golden transactions | Replay orders, invoices and goods movements end to end | Same business outcome as legacy |
| Interface replay | Run inbound and outbound interfaces with test data | All messages processed and reconciled |
| Period-end simulation | Run a close and reporting cycle on migrated data | Headline KPIs within agreed tolerance of legacy |
| Performance under load | Run key reports and batch jobs at representative volume | Within agreed response and runtime targets |
Build testing around critical processes
Create a critical-process inventory across supply chain, finance, manufacturing, and reporting. For each process, choose golden transactions such as an order, an invoice, and a goods movement, and replay them end to end with real roles and authorizations. Add interface replay with test messages, a period-end simulation, and parallel reporting on headline KPIs. A fuller framework for SAP data migration validation techniques can help structure those checks into a repeatable cycle.
Agree explicit rollback thresholds before the final rehearsal. Deciding during cutover which defects are acceptable guarantees an argument at the worst moment.
Go-live requires signed reconciliation results, business-owner acceptance, application restart and rebind testing, and a tested restore. After cutover, separate migration defects from normal process change with a simple rule. If legacy data replayed through the new process gives a different result, log it as a migration defect with the data owner. If the result matches and users dislike the new process, route it as process change. Mixing the two queues hides real defects inside change requests.
Run Hypercare and Book Your Readiness Review
Hypercare should follow a timed sequence with named owners and clear exit criteria. The database starting is only one checkpoint. Business continuity depends on resolving issues that affect processing and making reliable decisions from reconciled data.
The hypercare sequence
- Days 0 to 3: Monitor dumps, locks, interface errors, and batch timings hourly. Prioritize failures that block business processing over cosmetic issues.
- Weeks 1 and 2: Reconcile critical KPIs against legacy reports daily. Investigate variances while the legacy comparison remains available, and have business owners sign off on data they own.
- First close cycle: Run parallel reporting and compare results line by line. Valid but incorrect data often surfaces during close.
- Month one: Review anomalies weekly. Keep a change log that distinguishes migration defects from normal process changes, with an owner assigned to each defect.
Control emergency fixes. Require a record, an accountable owner, and a verification method before anyone changes production data or code. Retire legacy access paths and the fallback copy on a planned date once exit criteria are met. Keeping both available without a firm end date encourages workarounds and weakens confidence in the new system.
Tune HANA against actual workloads. Review memory consumption, check partitioning on the largest tables, and compare demand with business peaks before resizing. First-week behavior may not reflect sustained workload, so avoid sizing decisions based only on early observations.
Book a readiness review before the cutover date is fixed. Check scope, named data owners, the RFC inventory, and the results of a timed mock run using production-like volume. Kagool can support planning and validation with Pulse, and no-code SAP to Azure ingestion with Velocity. Start with the inventory and mock-run measurements to test whether the schedule is achievable.
If named data owners, a timed mock run, or a tested rollback are still missing, make those the first review gates. Kagool supports SAP migration planning, validation, and data ingestion, with cutover readiness judged by business continuity and dependable decisions, not merely whether the HANA database starts. Book the review before the next rehearsal date is fixed.
