From legacy replication to tested ERP disaster recovery, for a Sri Lankan manufacturing organisation

A manufacturing organisation was running its ERP on a database the business could not operate without, and the platform doing the replication and backup underneath it was reaching end of life. Replacing one standalone replication product with another would have solved the immediate problem and recreated the long-term one: another separate tool to license, patch, monitor and eventually migrate off again.

The production database was already protected inside its primary data centre by an Always On availability group. What it did not have was protection against losing the data centre — and, more to the point, any practical way to find out whether recovery would work. A single availability group stretched across both sites would have coupled them: site-level work touches the production replicas, and a disaster-recovery test means interrupting the thing you are protecting.

Which is why so many disaster-recovery plans are never tested. If testing costs an outage, the test gets postponed until it is needed, and the first real failover is also the first failover.

Two availability groups, joined. The existing production group kept doing its job inside the primary data centre. At the recovery site we built a second two-node Windows Server failover cluster with its own availability group, so the DR location has local resilience of its own rather than being one server someone hopes will be enough.

The two groups are then connected by a distributed availability group, which replicates between the groups rather than between individual replicas. Each location has its own listener, so applications connect to a name at whichever site they are meant to be using and never need to know which replica is currently primary.

That gives two distinct levels of protection: server-level resilience within each data centre, and site-level replication between them. The distinction matters more than it sounds. A single replica at another site gives you another copy of the database. A disaster-recovery architecture has to answer what happens when servers, database services, application connections or an entire location go away — and they are four different questions.

It also retired the end-of-life dependency rather than replacing it. The remote replication now runs inside the SQL Server high-availability architecture itself, on the database engine the ERP platform was already built on, so there is one technology to operate instead of two.

Infrastructure without a recovery procedure still leaves the IT team working out what to do during the outage. So the engagement delivered the runbook as well as the architecture: check distributed availability group health, confirm the state of the recovery environment, fail the database workload across to the DR availability group, validate the new primary, redirect the ERP application to the DR-side listener, and release the system for application and integration testing before the business is let back on.

Every one of those is a step someone would otherwise be inventing at the worst possible moment, with the business watching.

The client moved off an end-of-life replication platform onto a SQL Server-native architecture spanning two data centres: local high availability at each site, cross-site replication between them, defined connection points for production and recovery, monitoring the operations team can read, and written procedures for both a test and a real disaster.

The value was never the extra nodes. It was turning disaster recovery from a line in a document into something the business can exercise on a schedule and watch succeed — so the conversation changes from "we have a DR environment" to "we know how to use it".