India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP Migration Planning: Path, Downtime Budget, Mock Runs and Cutover
SAP migration planning is the work of choosing the transition path, migration technique and sequence for moving SAP systems to cloud, then proving the downtime with rehearsals. NTSPL selects brownfield, greenfield or selective transition with DMO or system-copy methods, sets a downtime budget, schedules mock runs around Indian close and GST dates, and writes the cutover runbook.
Delivered on
In scope
Why SAP Moves Slip on Downtime and Calendar Rather Than Infrastructure
Most SAP migration plans fail on the calendar, not the technology. A conversion weekend is booked, the first mock run takes 71 hours against a 40-hour window, and the only free weekend left falls in the week GSTR-3B is due or right before a quarterly board meeting. Meanwhile finance has not reconciled the conversion of customer and vendor master data to business partners, and the plant MES team learns about the freeze two days before it starts.
NTSPL plans from the downtime budget backwards. We agree the maximum business outage with the CFO and plant heads, pick the technique that can fit it, from classic DMO and DMO with system move to downtime-optimized DMO or HANA system replication for like-for-like moves, and then schedule at least two timed mock runs on production-sized copies. Each step in the cutover runbook carries an owner, a duration measured in rehearsal and a go or no-go checkpoint.
When an SAP Programme Needs a Dedicated Migration Plan
Signals you need SAP Migration Planning
- A business downtime of 48 hours or less has been mandated for a database larger than 3 TB.
- The programme involves more than one production SAP system moving in a sequence, such as ECC, BW and PI/PO.
- The finance team needs customer-vendor integration, new asset accounting or Universal Journal reconciliation built into the cutover.
- Plants, depots or dealer systems must keep running through the freeze and the order backlog must be re-entered after go-live.
- A previous mock run overran its window by more than 25 percent.
When to choose something else
- The landscape has not yet been checked for sizing, add-ons, Unicode and interfaces; run the SAP cloud readiness assessment first.
- Only non-production systems are moving for a test project; a simple system copy plan is enough.
- SAP will be re-implemented greenfield with no data migration beyond open items and masters; a data-migration and rollout plan fits better than a conversion plan.
Planning Workstreams Inside an SAP Migration Plan
Transition path selection
Brownfield conversion, greenfield implementation or selective data transition per system, scored on custom code, process change appetite, history needs and timeline.
Migration technique and downtime budget
Choice of SUM DMO, DMO with system move, downtime-optimized DMO, Software Provisioning Manager export and import, or HANA backup and HSR-based moves, with a modelled runtime.
Mock run programme
Number, scope and timing of mock conversions, production-sized copy refresh plan, and runtime tracking against the budget.
Business calendar and freeze
Cutover dates set around month-end, quarter-close, GST filing dates, plant shutdowns and peak sales seasons, with a freeze plan per function.
Cutover runbook and fallback
Hour-by-hour runbook with owners, measured durations, go or no-go checkpoints and a tested rollback to the source system.
Downtime-Budget-First Planning Model for SAP Cutovers
Downtime-Budget-First SAP Cutover Planning Model
The agreed business downtime sets the technical budget, which drives technique selection and the mock-run programme. Measured mock runtimes feed the runbook, which passes a final go or no-go review before the production weekend.
Select any component
Downtime-Budget-First SAP Cutover Planning Model: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Migration Tooling and Data Transfer Options per Cloud
For DMO with system move to AWS, export files are transferred over Direct Connect or to S3 in Mumbai; very large legacy databases with thin links need an AWS Partner offline transfer for the initial copy, since Snowball Edge closed to new customers in November 2025.
On Azure, NTSPL typically stages DMO system-move exports through ExpressRoute into Blob Storage or directly to the target VM, with Data Box reserved for offline seeding.
On Google Cloud, exports land in Cloud Storage in Mumbai over Interconnect, and Workload Manager checks the target hosts before the import phase.
Path and Technique Choices That Set the Downtime
Brownfield, greenfield or selective
Choose brownfield conversion when custom code is broadly fit, history must stay online and the business wants minimal process change. Choose greenfield when more than half of processes will be redesigned or the ECC was heavily modified. Selective data transition suits groups merging company codes or carving out a business, but needs specialist tools and longer testing.
Classic DMO, system move or downtime-optimized DMO
Classic DMO in place suits databases up to about 3 TB with a good network. DMO with system move separates export on-prem from import on cloud and suits most moves. Consider downtime-optimized DMO when the database exceeds 5 TB and downtime is under 36 hours; it moves selected large tables in uptime but adds setup and testing effort.
Number of mock runs
Plan at least two full mock runs plus a dress rehearsal for any production conversion. Add a third mock if mock 2 exceeds the technical budget by more than 10 percent or if finance reconciliation fails. Each mock must use a production copy no older than four weeks so table sizes reflect reality.
Cutover date selection
Avoid the five working days after month-end and the days around GSTR-1 and GSTR-3B due dates. Prefer a long weekend or a planned plant shutdown. For seasonal businesses, cut over in the lowest-volume month and keep at least two clean month-ends after go-live before the next peak season.
Planning Sequence from Path Decision to Signed Runbook
Constraint capture and calendar
Agree downtime budget, freeze rules and the 12-month business calendar with finance, plants and sales.
Path and technique selection
Decide transition path and migration technique per system, with modelled runtimes and network needs.
Mock programme design
Schedule mocks, copy refreshes and validation scripts, and assign owners for each reconciliation.
Runbook drafting and refinement
Build the hour-by-hour runbook and refine durations from measured mock results.
Go or no-go governance
Run checkpoint reviews and confirm rollback readiness before the production weekend.
What you receive
Planning Quality Indicators for an SAP Cutover
| KPI | Typical target |
|---|---|
| Mock 2 technical runtime against budget | At or below 90 percent of technical slice |
| Runbook steps with measured durations | 100 percent before dress rehearsal |
| Finance reconciliation exceptions at dress rehearsal | Zero unexplained differences in trial balance |
| Actual cutover duration against plan | Within plus or minus 10 percent |
Calendar and Rehearsal Risks in SAP Migrations
| Risk | How NTSPL prevents it |
|---|---|
| Mock runs use stale copies and underestimate table growth | Copies are refreshed within four weeks of each mock, and the 20 largest tables are tracked for growth between runs. |
| Cutover lands on a statutory or close date after a slipped mock | Two fallback cutover dates are approved upfront, both checked against GST and close calendars. |
| Rollback is planned but never tested | The dress rehearsal includes a timed rollback to the source system up to the first business validation checkpoint. |
Brownfield or greenfield S/4HANA when moving to cloud?
Brownfield conversion is faster and keeps history, configuration and custom code, so most Indian manufacturers with a stable ECC choose it. It typically takes 6 to 9 months and the downtime is one weekend. Greenfield is right when the ECC no longer reflects how the business works, for example after mergers or when more than half of processes will be redesigned; expect 12 to 18 months and a data-migration project for open items and masters. If you cannot decide, the custom-code usage profile is the best tiebreaker: if fewer than 40 percent of custom objects are still used, greenfield becomes much easier to justify.
Key facts: SAP Migration Planning
SAP Migration Planning in Practice
2 SAP Migration Planning scenarios, from Power transmission EPC and Ready-mix concrete, plus related platform case studies.
Power transmission EPC fits a 4.6 TB S/4HANA conversion into a 40-hour window
Ready-mix concrete firm sequences 3 SAP systems to Google Cloud around monsoon lows
Auto-ancillary maker converts ECC to S/4HANA on AWS inside a 48-hour downtime window
EPC company vacates its owned data centre in 7 months and halves run cost
SAP Migration Planning: Frequently Asked Questions
How much does SAP migration planning cost?
Planning effort for one production S/4HANA conversion with its tiers is usually 30 to 45 consultant-days spread over the programme, with most effort in the first four weeks and after each mock. Mock runs themselves need cloud capacity for a few days each, which is budgeted separately.
How do you plan around GST deadlines?
We mark GSTR-1 and GSTR-3B due dates, e-invoicing dependencies and month-end close on the programme calendar and exclude them from cutover candidates. E-invoice and e-way bill interfaces are tested in the dress rehearsal so invoicing works on the first business day after go-live.
Can plants keep working during the SAP downtime?
Usually yes, with a planned freeze. Plants record dispatches, receipts and production in MES or offline templates during the outage, and the runbook includes a timed backlog re-entry step after go-live with named owners per plant.
What is a realistic downtime for an S/4HANA conversion on cloud?
For databases between 2 and 6 TB, most Indian programmes fit a 36 to 48 hour window including business validation, using DMO with system move and tuned parallelism. Larger databases or tighter windows usually need downtime-optimized techniques.
Should non-production systems move first?
Yes. Sandbox and development move first so custom-code remediation runs on cloud, then quality for testing. Production moves last after mocks. This also proves network and operations processes before they matter.
Does migration planning cover data residency?
Yes. Export files, staging buckets and target systems are kept in Indian regions, transfer encryption is specified, and staging copies are deleted after cutover with evidence, which supports DPDP Act 2023 obligations for employee and customer personal data.