Case studies · Business Continuity
Charity & Social Services
core upgrade — H3C capability first, IRF redundancy second
failover tested against live applications
One building held the whole operation: domain controller, ERP, HRIS, file, print, document-management and device-management servers — twelve production workloads, roughly 13TB in daily use on about 20TB of provisioned storage, with nowhere to fail over to. A fire, a flood or a ransomware week would take the organisation's back office with it. And the network feeding those servers was itself a single path: aging switching with no cluster and no resilient framework between the servers and the core. Business continuity meant building both halves — a second site that could actually run the workloads, and a core network that would not be the reason it could not.
The core was rebuilt on H3C in two deliberate stages: an S6805 core switch and S5590 server-access switches first — the functional upgrade that could land immediately — then the high-availability layer added on top, with IRF (Intelligent Resilient Framework) clustering so the core behaved as one resilient logical device with no single switch standing between the servers and everything else. The phasing let the organisation bank the capability uplift without waiting on the redundancy project.
Azure became the second site. The subscription, virtual machines, storage and networking were stood up and sized against the actual server inventory — CPU, memory and provisioned storage recorded workload by workload — and Azure Site Recovery was installed on the on-premises servers to replicate the critical VMs to Azure, with replication frequency, retention and failover testing defined jointly with the customer's IT team rather than defaulted.
Identity went to the cloud with them: a domain controller was provisioned on Azure, AD DS installed and configured, and replication established between the on-premises controller and the Azure one — so at failover the recovered machines join a directory that already knows them, not an empty forest. The two networks were joined by an Azure VPN Gateway wired into the existing firewall configuration, and Traffic Manager staged to re-route users to the DR site when the primary goes dark — the last piece of a failover that ends with people back at their systems, not just servers running in a subscription nobody can reach.
Recovery was drilled, documented and handed over: controlled failover tests run against critical applications to measure real impact, regular DR drills to keep the path proven, and DR documentation with a UAT plan delivered as the project's written answer to 'what happens on the bad day'. Azure Backup was layered alongside Site Recovery for retention, so the DR site holds history as well as replicas. Hypervisor build, application changes and workstation work stayed explicitly on the customer's side of the line — scope drawn so both teams knew what 'done' meant.
The organisation now runs its business continuity plan on two grounds: the production H3C core — S6805 and S5590 under IRF — feeding Azure-replicated workloads through Site Recovery, a domain controller waiting in the cloud with AD replication already flowing, a VPN bridge between the sites, and Traffic Manager ready to move users. Failover has been tested, recovery steps documented, and drills put on a calendar — a DR site in the operational sense, not just a subscription.
Whether it’s a critical server issue or a long-term digital transformation project, our team is ready to assist. Reach out and experience ITR’s expert support that actually works.
