Those figures would be material for a company running logistics, finance, workforce and supply-chain processes across remote mining operations. But readers should treat them as customer-case-study results, not a published service-level commitment. NTT DATA has supplied the only detailed public account of the deployment; searches did not turn up a matching Microsoft customer story or a BUMA announcement independently documenting the architecture, cutover, costs, Azure regions or ongoing operating model.
The two NTT DATA items circulating under “BUMA SAP Migration to Azure” are also not two separate announcements. Both URLs resolve to the same NTT DATA case study, titled From complexity to resilience: BUMA’s SAP transformation on Microsoft Azure. The page describes one migration rather than a second phase, follow-on deal or separate Azure rollout.
A three-and-a-half-month migration of more than S/4HANA
According to NTT DATA, the work covered development, sandbox, quality-assurance and production systems, and completed over three and a half months. The scope went beyond an SAP S/4HANA database and application migration: NTT DATA says it moved SAP Solution Manager, PI NetWeaver, SAP Router, SAP Agents and connected systems, while also redesigning compute, storage, networking, identity and disaster recovery.
That detail is significant. SAP migration stories often flatten a complex collection of dependent systems into a single “S/4HANA on cloud” claim. The SAP application stack may be the visible business system, but services such as SAP Router, integration middleware and Solution Manager affect connectivity, interfaces, monitoring and operational support. A migration that leaves those dependencies behind can preserve infrastructure risk even if the central ERP workload reaches Azure.
NTT DATA says BUMA integrated its existing software-defined WAN with the Azure landing zone to improve access for more than eight operational sites and headquarters. The company attributes smoother transactions, lower round-trip times and more consistent peak performance to network changes, virtual-machine sizing, latency remediation and Azure Proximity Placement Groups.
There is an important boundary on that claim. Proximity Placement Groups are designed to place Azure compute resources close together within a region to reduce latency among those resources. They can improve application-to-database communication inside the SAP stack, but they cannot by themselves fix a poor or congested connection from a remote mining site to Azure. The reported improvement therefore depends substantially on the SD-WAN and network-remediation work, not simply on relocating SAP workloads to Azure.
NTT DATA does not identify the Azure regions used, the locations of BUMA’s operational sites, the network carriers, the virtual-machine families or the baseline and post-migration latency measurements. Without those details, other IT teams cannot tell whether the performance result came primarily from cloud capacity, WAN redesign, local connectivity upgrades, application tuning or a combination of all four.
The recovery numbers are real improvements, but the math needs context
NTT DATA’s published before-and-after numbers are the strongest part of the case study: a recovery time objective, or RTO, moving from about 24 hours to as low as four hours; and a recovery point objective, or RPO, falling from about 24 hours to 15 minutes.
An RTO describes how long a service may be unavailable after a disaster. RPO describes how much data loss, measured in time, the business is prepared to accept. A 15-minute RPO is a much more consequential change than a four-hour RTO for a mining operator: it means that after a site-level catastrophe, the business expects to lose no more than 15 minutes of committed data rather than potentially a day’s worth.
The percentage callouts in NTT DATA’s own page deserve closer reading. Reducing an RPO from 24 hours to 15 minutes is a reduction of about 99%, while the case study markets it as 98%. Reducing an RTO from 24 hours to four hours is an 83% reduction, while the page uses 80%. Neither shorthand changes the direction of the improvement, but both figures are rounded presentation numbers rather than precise operational measurements.
More importantly, the phrase “as low as” means four hours should not be read as a guaranteed recovery time in every event. Recovery duration changes with the affected component, available capacity in the disaster-recovery region, DNS and identity dependencies, database recovery, application startup order, validation requirements and the state of the network. Microsoft’s SAP guidance makes the same point: disaster-recovery procedures must be tested, documented and regularly refined because SAP systems have tightly coupled database, central-services, shared-storage, Active Directory and DNS dependencies.
NTT DATA says BUMA has carried out disaster-recovery drills with minimal operational interruption, but it provides no frequency, scenario, observed drill duration or evidence that a full regional failover has been exercised end to end. That does not negate the result; it identifies what remains unverified publicly. A short RPO is useful only if the failover runbook can consistently bring up the right data, services, identities and network paths in the correct sequence.
Azure Site Recovery is only part of an SAP disaster-recovery design
The published architecture names Azure Site Recovery, multiregion design and unspecified synchronization mechanisms. It also mentions network segmentation, premium storage, SAP-recommended VM sizes and Proximity Placement Groups.
Microsoft supports Azure Site Recovery for replicating SAP application tiers and for orchestrating regional failover. But Microsoft’s own SAP-on-Azure guidance distinguishes virtual-machine replication from the database layer: for databases running on Azure VMs, Microsoft recommends native database replication to synchronize data to the disaster-recovery location. For SAP HANA, that normally means a deliberate HANA replication and recovery design rather than assuming VM-level recovery alone will meet application-consistent RPO targets.
NTT DATA does not disclose whether BUMA uses SAP HANA System Replication, the replication mode, the storage configuration, the second Azure region, or how shared SAP files are replicated. Those omissions are material. They prevent an independent assessment of whether the reported 15-minute RPO applies to the whole S/4HANA service, only selected database data, or a particular tested failure scenario.
The case study does establish that the migration was not a simple lift-and-shift. NTT DATA says the project included proof-of-concept work with Microsoft and BUMA, performance benchmarks, remediation, phased migration and user testing before production go-live. It also says the client remained in operation during the transition. For a business-critical SAP rollout, that phased validation is more credible than a vague claim of “seamless transformation.”
Still, it is NTT DATA’s account of its own delivery. There are no stated availability targets, financial terms, Azure consumption estimates, managed-services commitments, SAP licensing changes or staffing outcomes. BUMA may have gained a more flexible infrastructure base, but cloud elasticity does not automatically mean lower cost; continuously replicated SAP HANA environments, premium storage, dedicated network connectivity and standby disaster-recovery capacity can be expensive by design.
AI is a future option, not an announced BUMA deployment
The case study also frames Azure as a foundation for AI-assisted forecasting, operational insight, predictive modelling and automation. That is forward-looking positioning, not evidence that BUMA has deployed an Azure AI workload against SAP data.
This distinction matters for administrators and procurement teams. Moving SAP to Azure can simplify integration with Microsoft’s data, identity, monitoring and automation services, but it does not resolve the work of building governed data pipelines, defining data ownership, protecting operational and personnel data, validating model outputs or changing business processes around forecasts. The migration creates capacity for those projects; it does not deliver them.
The more immediate result is operational: BUMA now has an Azure-hosted SAP environment designed around multiregion recovery, revised network paths and capacity that can be expanded without buying and installing on-premises hardware. For a mining contractor connecting geographically dispersed sites, that is a concrete infrastructure change.
The remaining test is not whether Azure can host SAP S/4HANA—it plainly can—but whether BUMA publishes evidence that its new four-hour RTO and 15-minute RPO hold during repeated, full-service disaster-recovery exercises. Until then, the case study supports a successful migration and a substantially better declared recovery design, while leaving the most consequential implementation details inside NTT DATA and BUMA.
References
- Primary source: NTT Data
Published: August 10, 2026 at 10:55 AM UTC
Loading…
www.nttdata.com - Independent coverage: NTT Data
Published: Mon, 10 Aug 2026 10:50:46 GMT
Loading…
www.nttdata.com - Related coverage: azure.microsoft.com
Loading…
azure.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: marketplace.microsoft.com
Loading…
marketplace.microsoft.com - Related coverage: microsoft.com
Loading…
www.microsoft.com - Related coverage: services.global.ntt
Loading…
services.global.ntt - Related coverage: azure.microsoft.com
Loading…
azure.microsoft.com - Related coverage: news.sap.com
Expanding Global RISE with SAP on Microsoft Azure Initiative | SAP News Center
SAP and Microsoft are expanding the global RISE with SAP on Microsoft Azure initiative for RISE with SAP on Microsoft Azure customers.news.sap.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: services.global.ntt
Loading…
services.global.ntt - Related coverage: nttdata-solutions.com
Loading…
nttdata-solutions.com - Related coverage: support.microsoft.com
Loading…
support.microsoft.com - Related coverage: microsoftlearning.github.io
Loading…
microsoftlearning.github.io - Related coverage: info.microsoft.com
Loading…
info.microsoft.com - Related coverage: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com