What IWG says it did
NTT DATA says IWG treated its application-hosting environment as a key organizational risk. The company needed key applications available around the clock for a global customer base. IWG decided to standardize on Azure for greater agility, availability and resilience, and as a base for application modernization.
According to NTT DATA, the project covered 176 servers and application workloads moved from on-premises to Azure. That specific sentence is from the NTT DATA page, not the search results, so treat it as vendor-reported. IWG's CIO, Andre Sharpe, is quoted as saying that corporate customers and new franchise partners made this the right time to invest in service, security and reliability.
The case study describes IWG as headquartered in Switzerland, with centers in 110 countries serving 2.5 million users across more than 3,300 locations. These are the company's own figures as repeated by NTT DATA. They have not been independently verified.
The migration pattern
NTT DATA says it followed Microsoft's Discover-Migrate-Optimize methodology:
- Discover: a Cloud Readiness Assessment inventoried and benchmarked the on-premises servers and application workloads.
- Migrate: the team used the Azure Migrate tool and moved workloads to platform as a service (PaaS) "where possible". The page does not say which workloads were replatformed and which stayed on virtual machines.
- Optimize: the team monitored the virtual machines and workloads, tuned the environment, looked for cost efficiencies, and worked on availability and scale.
- Disaster recovery: a full failover configuration was set up to an Azure data center in a separate geography.
The disaster-recovery description includes managed failover procedures and data replication. It also mentions automated failover for applications not built for high availability, and automated pipelines for PaaS applications. The page gives no region names, recovery time or recovery point objectives, or test results.
IWG first engaged another service provider before choosing NTT DATA for its Azure and managed-services capabilities. The page does not name that provider or explain why the change was made.
Claimed outcomes, and what is missing
NTT DATA reports that IWG:
- reduced operational risk and the resources needed to run its data center;
- increased application availability;
- improved security, with alerts monitored by NTT DATA's global security operations center.
The case study gives no figures for uptime, downtime, cost, security incidents or staffing. The outcomes are qualitative. Nothing on the page lets a reader measure them.
NTT DATA also says IWG's web-development team was freed from operational support to work on a new customer portal. It describes IoT work at the centers and real-time intelligent pricing models. The page presents these as planned initiatives, not delivered results.
A note on the identity claim
The case study credits "Azure Active Directory" with reducing identity-management problems and identity theft. It gives no baseline or measurement method. That product has since been renamed. Microsoft announced that Azure AD was being renamed Microsoft Entra ID, and Wikipedia dates the announcement to July 11, 2023. Microsoft's guidance said "No action is needed from customers". Microsoft Learn says the rename was meant to convey multicloud, multiplatform functionality and reduce confusion with Windows Server Active Directory.
The case study doesn't say when IWG deployed its identity setup. Administrators reading older Azure migration write-ups should expect the old product name and map it to Entra ID. The Entra ID Free, P1 and P2 licensing tiers kept their capabilities under the new names.
Takeaways for IT teams
The page is not an implementation guide, and it can't show that the same approach will deliver the same availability or savings elsewhere. It does illustrate a sensible sequence:
- Inventory and benchmark first. Know what you are moving before you move it.
- Decide per workload. PaaS suits some applications and not others. The case study says PaaS was used "where possible", not everywhere.
- Tune after cutover. Monitoring and optimization are part of the project, not an afterthought.
- Treat disaster recovery as a deliverable. Replication and failover in a separate geography are what separate a lift-and-shift from a resilient design. They need documented recovery objectives and tests, which this page does not provide.
- Ask vendors for numbers. If you are evaluating a migration partner, ask for measured availability, recovery objectives and cost baselines, not only qualitative outcomes.
Overall, the case study confirms that IWG moved 176 workloads to Azure with a separate-geography failover design and a managed security-monitoring service. It offers no independent evidence of how well the result performs.